Source code
package io.netty.example.sctp;
import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer; import io.netty.channel.ChannelOption;
import io.netty.channel.EventLoopGroup; import io.netty.channel.MultiThreadIoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.channel.sctp.SctpChannel;
import io.netty.channel.sctp.nio.NioSctpServerChannel; import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler; /**
* Echoes back any received data from a SCTP client.
*/
public final class SctpEchoServer {
static final int PORT = Integer.parseInt(System.getProperty("port", "8007")); public static void main(String[] args) throws Exception { // Configure the server.
EventLoopGroup group = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
final SctpEchoServerHandler serverHandler = new SctpEchoServerHandler();
try {
ServerBootstrap b = new ServerBootstrap(); b.group(group) .channel(NioSctpServerChannel.class) .option(ChannelOption.SO_BACKLOG, 100)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SctpChannel>() { @Override
public void initChannel(SctpChannel ch) throws Exception {
ch.pipeline().addLast( //new LoggingHandler(LogLevel.INFO),
serverHandler);
} });
// Start the server.
ChannelFuture f = b.bind(PORT).sync();
// Wait until the server socket is closed.
f.channel().closeFuture().sync();
} finally {
// Shut down all event loops to terminate all threads.
group.shutdownGracefully();
}
} }
Run 1
The code has a clear overall structure with logical imports, a try-finally block, and relevant comments explaining the server steps, but its readability is significantly hurt by poor formatting and layout. Several lines contain multiple imports or multiple actions, causing some lines to exceed conventional length and making scanning difficult. The builder chain mixes method calls on the same line as assignments and nested anonymous class declarations, which reduces the reading flow and action granularity. Nesting depth is acceptable, but the anonymous ChannelInitializer inline weakens clarity. Renaming b to bootstrap and splitting imports and method chains onto separate lines would improve readability considerably.
Run 2
The code has modular structure and brief comments but is severely marred by poor formatting: multiple statements on single lines, inconsistent indentation, and jumbled imports. This makes scanning difficult and obscures the logical flow. Nesting is mostly flat, which is positive, but the chained ServerBootstrap configuration and anonymous inner class further reduce readability due to condensed layout. Intent is clear overall—an echo server—yet the presentation creates unnecessary cognitive load. The code is not excessively long, but action granularity suffers from multiple imports and statements per line. Reading flow is disrupted; the code feels messy despite being conceptually simple. With standard formatting (one statement per line, consistent indentation, organized imports), readability would improve dramatically.
Run 3
The code has significant readability issues. The structure is tangled, with multiple import statements and code blocks compressed onto single lines, making it difficult to scan. Nesting is moderate but worsened by inconsistent formatting. The intent is not immediately clear due to poor layout, although the comment helps slightly. Code length is reasonable for the logic but inefficiently formatted. Action granularity is poor; multiple statements are packed into single lines, especially in the main method and imports. Reading flow is disrupted by irregular indentation and line breaks. Overall, the code would be far more readable with proper formatting, consistent spacing, and one action per line.
Run 1
Code Structure: Server setup, binding, waiting, and cleanup are logically organized, but compressed formatting obscures their boundaries. Nesting: Moderate nesting from try/finally and an anonymous channel initializer is manageable. Clarity of intent: The class name, documentation, and lifecycle comments clearly communicate an SCTP echo server; abbreviated variables and commented-out logging slightly reduce clarity. Code length: Concise overall, with little unnecessary code, although excessive compression hurts readability. Action granularity: Multiple imports, declarations, and statements share lines, making individual actions harder to distinguish. Reading flow: The execution sequence is natural, but inconsistent indentation, crowded method boundaries, awkward fluent-chain formatting, and combined closing braces interrupt scanning.
Run 2
Code Structure: The server follows a logical setup, bind, wait, and cleanup sequence, but compressed declarations and inconsistent formatting obscure its organization. Nesting: Moderate nesting from try/finally and the anonymous channel initializer is justified and manageable. Clarity of intent: The class name, documentation, and lifecycle comments clearly identify an SCTP echo server; the abbreviated variable names and commented-out logging code slightly reduce clarity. Code length: Appropriately concise for a small server example, though compression sacrifices readability rather than eliminating unnecessary code. Action granularity: Multiple imports, declarations, and bootstrap operations share lines, making individual actions harder to scan. Reading flow: The execution order is natural, but uneven indentation, crowded method boundaries, and irregular fluent-chain formatting interrupt reading.
Run 3
Code Structure: Server configuration, startup, waiting, and cleanup are logically organized, but compressed declarations and inconsistent formatting obscure boundaries. Nesting: Moderate nesting from try/finally and the anonymous channel initializer is manageable. Clarity of intent: The class name, documentation, and lifecycle comments clearly establish an SCTP echo server; abbreviated variables and commented-out logging add minor ambiguity. Code length: Concise overall, without substantial unnecessary logic, although compression sacrifices readability. Action granularity: Multiple imports, declarations, and bootstrap operations share lines, making individual actions harder to scan. Reading flow: Execution follows a natural setup-to-cleanup sequence, but irregular indentation, inline annotations, crowded braces, and inconsistent fluent-chain formatting interrupt that flow.