In arcp-core/src/main/java/dev/arcp/core/transport/MemoryTransport.java the pair static factory at line 23 returns a MemoryTransport[] of length 2. Callers must read the Javadoc to learn that index 0 is "a" and index 1 is "b" — there is no compile-time guarantee, no IDE autocomplete for the field names, and a typo at the call site that swaps indices silently builds against the wrong end of the pair. Java records exist precisely to express this pattern.\n\nThe pattern shows up across every test in the SDK (arcp-runtime, arcp-client, arcp-tck, examples), so the readability win compounds. The current callers all use array destructuring like MemoryTransport[] pair = MemoryTransport.pair(); var server = pair[0]; var client = pair[1]; which is exactly the kind of code records were designed to replace.\n\nFix prompt: In arcp-core/src/main/java/dev/arcp/core/transport/MemoryTransport.java introduce a public nested record public record Pair(MemoryTransport client, MemoryTransport server) {} (or whichever orientation matches current conventions — verify by reading any existing call site first), change pair() to return Pair, and update the internal construction to populate the record. Then update every call site across the modules (use ./gradlew compileTestJava to surface them) to use pair.client() and pair.server() or var destructuring with record pattern matching: Pair(var client, var server). The change improves call-site readability and gives the compiler enough information to flag mistakes. As an alternative, return a Map.Entry<MemoryTransport, MemoryTransport> — the record is preferred because the field names carry meaning.
In arcp-core/src/main/java/dev/arcp/core/transport/MemoryTransport.java the pair static factory at line 23 returns a
MemoryTransport[]of length 2. Callers must read the Javadoc to learn that index 0 is "a" and index 1 is "b" — there is no compile-time guarantee, no IDE autocomplete for the field names, and a typo at the call site that swaps indices silently builds against the wrong end of the pair. Java records exist precisely to express this pattern.\n\nThe pattern shows up across every test in the SDK (arcp-runtime, arcp-client, arcp-tck, examples), so the readability win compounds. The current callers all use array destructuring likeMemoryTransport[] pair = MemoryTransport.pair(); var server = pair[0]; var client = pair[1];which is exactly the kind of code records were designed to replace.\n\nFix prompt: In arcp-core/src/main/java/dev/arcp/core/transport/MemoryTransport.java introduce a public nested recordpublic record Pair(MemoryTransport client, MemoryTransport server) {}(or whichever orientation matches current conventions — verify by reading any existing call site first), change pair() to return Pair, and update the internal construction to populate the record. Then update every call site across the modules (use./gradlew compileTestJavato surface them) to usepair.client()andpair.server()or var destructuring with record pattern matching:Pair(var client, var server). The change improves call-site readability and gives the compiler enough information to flag mistakes. As an alternative, return aMap.Entry<MemoryTransport, MemoryTransport>— the record is preferred because the field names carry meaning.