Source code
package io.netty.testsuite.transport.socket;
import io.netty.bootstrap.Bootstrap;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.Channel;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.IoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.testsuite.transport.TestsuitePermutation;
import io.netty.util.NetUtil;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;
import org.junit.jupiter.api.Timeout;
import java.nio.channels.AlreadyConnectedException;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class SocketMultipleConnectTest extends AbstractSocketTest {
@Test
@Timeout(value = 30000, unit = TimeUnit.MILLISECONDS)
public void a(TestInfo a) throws Throwable {
b(a, new Runner<ServerBootstrap, Bootstrap>() {
@Override
public void b(ServerBootstrap b, Bootstrap c) throws Throwable {
a(b, c);
}
});
}
public void a(ServerBootstrap d, Bootstrap e) throws Exception {
Channel f = null;
Channel g = null;
try {
d.childHandler(new ChannelInboundHandlerAdapter());
f = d.bind(NetUtil.LOCALHOST, 0).syncUninterruptibly().channel();
e.handler(new ChannelInboundHandlerAdapter());
g = e.register().syncUninterruptibly().channel();
g.connect(f.localAddress()).syncUninterruptibly();
ChannelFuture h = g.connect(f.localAddress()).await();
assertTrue(h.cause() instanceof AlreadyConnectedException);
} finally {
if (g != null) {
g.close();
}
if (f != null) {
f.close();
}
}
}
@Override
protected List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> c() {
List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> i
= new ArrayList<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>>();
for (TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap> j
: SocketTestPermutation.INSTANCE.socketWithFastOpen()) {
EventLoopGroup k = j.newClientInstance().config().group();
if (k instanceof IoEventLoopGroup && ((IoEventLoopGroup) k).isIoType(NioIoHandler.class)) {
i.add(j);
}
}
return i;
}
}
Run 1
The code is difficult to read primarily because of meaningless single-letter names like 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k'. This makes it hard to understand the intent of methods and variables, regardless of structure. Method names like 'a()' and 'b()' are especially problematic. The code has reasonable structure with a test method and a helper, but the helper's purpose is unclear due to naming. Nesting is minimal, which is good. Code length is concise, but this comes at the cost of clarity. Action granularity is mostly acceptable, with one action per line. Reading flow is natural in terms of logical sequence, but the cryptic identifiers destroy comprehension. The class is a test, but parameter names in test methods (TestInfo a) and anonymous inner class methods are all opaque. Overall, the code is structurally sound but fails badly on clarity of intent due to terrible naming.
Run 2
The code is severely unreadable due to single-letter variable and method names (a, b, c, d, e, f, g, h, i, j, k), which completely obscure intent. Method names like 'a', 'b', and 'c' provide no indication of their purpose. The nested anonymous inner class adds unnecessary complexity and indirection. While structure follows basic test setup patterns, the obfuscated naming defeats clarity and maintainability. Multiple operations per line, such as chained bind/sync/channel calls, violate action granularity. Import organization is non-standard (no grouping). The code appears intentionally obfuscated, resembling decompiled or minimized source rather than human-written code. Even though the logical flow is linear and flat, the naming alone drops readability to near zero. This would be extremely difficult for a developer to understand, modify, or debug without significant reverse-engineering effort.
Run 3
The code is extremely hard to read due to single-letter or meaningless variable and method names (e.g., a, b, c, d, e, f, g, h). This destroys clarity of intent, making it impossible to infer what each component does without deep inspection. The method overloading with identical names adds confusion. The nested anonymous class and deeply nested control flow increase cognitive load. While some structure exists (try-finally, separation of client/server bootstrap), the overall readability is severely compromised. Code length is moderate, but the action granularity and reading flow suffer because actions are grouped behind ambiguous identifiers. The code essentially abandons self-documentation.
Run 1
Code Structure: Methods separate test setup, connection verification, and bootstrap filtering logically. Nesting: Mostly shallow, with manageable try/finally cleanup and a loop containing one conditional. Clarity of intent: The class name, API calls, and assertion reveal the test purpose, but single-letter method and variable names severely obscure roles and relationships. Code length: Reasonably concise, though verbose generic declarations and anonymous runner boilerplate add visual overhead. Action granularity: Most lines perform one logical action; chained asynchronous calls are conventional but require some interpretation. Reading flow: Setup, connection attempts, assertion, and cleanup follow a natural sequence. However, overloaded methods named 'a', delegation through 'b', and filtering in 'c' force readers to infer meaning rather than obtain it directly from names.
Run 2
Code Structure: Methods separate test execution, connection behavior, and bootstrap filtering logically. Nesting: Mostly shallow, with manageable try/finally, null checks, and a loop containing one condition. Clarity of intent: The class name, Netty calls, and assertion reveal the test's purpose, but single-letter method and variable names severely obscure roles and relationships. Code length: Reasonably concise, although verbose generic declarations and anonymous runner boilerplate add reading overhead. Action granularity: Statements generally perform one action per line; fluent call chains remain understandable. Reading flow: Setup, connection attempts, assertion, and cleanup follow a natural sequence, but opaque identifiers and dense type expressions require repeated interpretation.
Run 3
Code Structure: Logically separates test execution, connection checks, and bootstrap filtering, with reliable cleanup in finally. Nesting: Mostly shallow; the anonymous runner and conditional cleanup introduce manageable nesting. Clarity of intent: The class name, API calls, and assertion reveal the test purpose, but single-letter method and variable names significantly obscure roles and relationships. Code length: Reasonably concise, though repeated generic types and anonymous-class boilerplate add visual weight. Action granularity: Generally one statement per line; chained calls combine related operations without excessive complexity. Reading flow: Setup, connection attempts, assertion, and cleanup follow a natural sequence, but cryptic identifiers and long generic declarations interrupt comprehension.