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 testMultipleConnect(TestInfo testInfo) throws Throwable {
run(testInfo, new Runner<ServerBootstrap, Bootstrap>() { @Override
public void run(ServerBootstrap serverBootstrap, Bootstrap bootstrap) throws Throwable { testMultipleConnect(serverBootstrap, bootstrap);
}
}); } public void testMultipleConnect(ServerBootstrap sb, Bootstrap cb) throws Exception {
Channel sc = null;
Channel cc = null; try {
sb.childHandler(new ChannelInboundHandlerAdapter()); sc = sb.bind(NetUtil.LOCALHOST, 0).syncUninterruptibly().channel();
cb.handler(new ChannelInboundHandlerAdapter());
cc = cb.register().syncUninterruptibly().channel();
cc.connect(sc.localAddress()).syncUninterruptibly();
ChannelFuture connectFuture2 = cc.connect(sc.localAddress()).await();
assertTrue(connectFuture2.cause() instanceof AlreadyConnectedException); } finally {
if (cc != null) {
cc.close();
}
if (sc != null) {
sc.close(); }
}
}
@Override
protected List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> newFactories() { List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> factories = new ArrayList<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>>();
for (TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap> comboFactory : SocketTestPermutation.INSTANCE.socketWithFastOpen()) { EventLoopGroup group = comboFactory.newClientInstance().config().group();
if (group instanceof IoEventLoopGroup && ((IoEventLoopGroup) group).isIoType(NioIoHandler.class)) {
factories.add(comboFactory); } } return factories; }
}
Run 1
The code has severe readability issues. Multiple imports are placed on the same line, annotations are embedded within method declarations, and methods are collapsed onto single lines. The testMultipleConnect method mixes resource setup, connection logic, and assertions without clear separation, making the intent hard to follow. Action granularity is poor as multiple operations happen per line in several places. The newFactories() method is particularly dense, with nested conditional logic and long lines containing multiple method calls. The structure violates typical Java formatting conventions, making the code appear tangled despite relatively simple underlying logic. While variable names are somewhat descriptive, the overall organization and formatting significantly impair readability.
Run 2
The code has severe readability issues. Imports are compressed onto single lines, making them hard to scan. The class and method structure is flattened with multiple methods and annotations on the same line, obscuring the logical organization. The nesting is moderate but the inconsistent and compressed formatting creates a tangled appearance. Intent is not immediately clear due to the formatting rather than the code logic itself. The code is unnecessarily long in terms of lines because multiple statements are jammed together, yet the formatting also wastes space by not using conventional line breaks. Action granularity suffers significantly; several lines contain multiple statements, mixing actions like variable declarations, method calls, and annotations. The reading flow is disrupted by the non-standard layout, forcing the reader to parse dense, visually cluttered lines. While the underlying logic may be straightforward, the presentation makes it nearly unreadable and fails to meet standard Java formatting conventions.
Run 3
The code suffers from multiple readability issues. The package and imports are compressed onto single lines using semicolons, making them difficult to scan. Method signatures and multiple annotations are crammed together without line breaks. The test method bodies have minimal separation between statements, creating visual clutter. Variable declarations use non-descriptive names like 'sb', 'cb', 'sc', and 'cc' without comments explaining their purpose. The newFactories method has deeply nested logic with multiple chained calls on one line and a complex condition, making it hard to follow. The finally block has inconsistent spacing and brace placement. Reading flow is interrupted by the inconsistent application of line breaks—some sections are overly compact while others have awkward breaks mid-expression. The overall structure does not follow consistent formatting conventions and lacks the vertical spacing needed to distinguish logical sections within methods.
Run 1
Code Structure: Separate methods organize test execution, connection checks, and factory filtering logically, but compressed formatting obscures boundaries. Nesting: Moderate nesting from the anonymous runner, try/finally, and loop/conditional is manageable. Clarity of intent: The test name and AlreadyConnectedException assertion clearly express the purpose; abbreviated channel and bootstrap names reduce clarity. Code length: The implementation is reasonably concise, although verbose generic types add visual noise. Action granularity: Multiple imports, declarations, statements, annotations, and closing braces share lines, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks and indentation interrupt otherwise natural setup, execution, assertion, and cleanup sequencing. Overall, the logic is understandable, but presentation substantially reduces readability.
Run 2
Code Structure: Separate test entry, connection test, and factory-selection methods provide logical organization, but compressed formatting obscures their boundaries. Nesting: Moderate nesting from the anonymous runner, try/finally, loop, and conditionals remains manageable. Clarity of intent: The test name and AlreadyConnectedException assertion clearly convey the purpose; abbreviated variables and verbose generic types reduce clarity. Code length: The implementation is reasonably concise, although repeated generic declarations add visual weight. Action granularity: Multiple imports, statements, annotations, and method boundaries share lines, making individual actions difficult to distinguish. Reading flow: Inconsistent brace placement, sparse spacing, and densely packed lines repeatedly interrupt otherwise straightforward execution and cleanup flow.
Run 3
Code Structure: Test execution, connection verification, and factory filtering are logically separated into methods, but compressed formatting obscures boundaries. Nesting: Mostly moderate, with an anonymous runner, try/finally cleanup, and a loop containing a conditional; not excessively deep. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose, although abbreviated names such as sc, cc, sb, and cb reduce clarity. Code length: Reasonably concise, but verbose generic types and runner boilerplate add reading overhead. Action granularity: Multiple imports, declarations, statements, annotations, and closing braces share lines, making individual actions harder to distinguish. Reading flow: Execution proceeds logically from setup through connection attempts to cleanup, but inconsistent line breaks and indentation disrupt scanning, especially in newFactories.