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 {
if (((0xA3AD ^ 0xA3AD) != 0)) { throw new AssertionError(); }
// 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 {
if (((0x8A5B ^ 0x8A5B) != 0)) { throw new AssertionError(); }
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 configuration of a Netty server, but several issues harm readability. The meaningless `if (((0xA3AD ^ 0xA3AD) != 0)) { throw new AssertionError(); }` lines are confusing and add noise—they appear to be dead code or injected artifacts. The class-level constant `PORT` is overexposed as `static final` without `private`, and its initialization via `Integer.parseInt` on a system property makes it less obvious at first glance. The anonymous `ChannelInitializer` adds one level of nesting, which is acceptable but slightly reduces flatness. The fluent builder chain is well-formatted and readable, with one action per line. However, the commented-out `LoggingHandler` line creates ambiguity about intent. Error handling relies on `throws Exception`, which hides potential failure points. Overall, the code is functional and structured but could be clearer by removing the artifact lines, making the constant private, and improving exception handling.
Run 2
This code has decent structure with logical separation of concerns and clear comments, but contains problematic elements that reduce readability. The dead code `if (((0xA3AD ^ 0xA3AD) != 0)) { throw new AssertionError(); }` appears twice and is confusing - these are meaningless conditions that always evaluate to false, serving no purpose in production code. Indentation is inconsistent around these statements, disrupting the visual flow. The anonymous inner class for ChannelInitializer adds nesting depth, though this is standard Netty boilerplate. Imports are not alphabetically organized. The method chaining in the ServerBootstrap setup is clean and readable. Comments are concise and helpful. The code demonstrates reasonable action granularity with one operation per line in most cases. Overall, the core logic is understandable, but the mysterious assertion statements and inconsistent indentation significantly lower the readability score from what would otherwise be around 16-17.
Run 3
The code demonstrates good structure with a clear separation of concerns: configuration, handler setup, server startup, and graceful shutdown. The read flow follows a logical top-to-bottom progression. However, there are minor readability issues: dead code assertions (e.g., `if (((0xA3AD ^ 0xA3AD) != 0)) { throw new AssertionError(); }`) add confusion and unnecessary length, and a commented-out logging handler should be removed. Nesting is flat, with only one level inside the anonymous `ChannelInitializer`. Most lines perform a single action, promoting clarity. The fluent API chaining (`.group().channel().option()` etc.) is well-formatted, though slightly dense. Overall, the code is highly readable for a Netty server example, with only minor cleanups needed to reach near-perfect clarity.
Run 1
Code Structure: Server setup, binding, waiting, and cleanup are logically organized, with lifecycle management clearly expressed through try/finally. Nesting: Moderate nesting from the anonymous initializer is manageable. Clarity of intent: The class documentation and comments explain the echo server, but two always-false hexadecimal XOR checks introduce confusing, unnecessary noise; short names b and f are less descriptive. Code length: Generally concise, though the redundant checks and commented-out logging statement add clutter. Action granularity: Most statements perform one action, and fluent configuration uses one call per line; the inline checks combine condition and throw on a single line. Reading flow: The lifecycle reads naturally, but badly indented checks interrupt the otherwise consistent formatting.
Run 2
Code Structure: Server configuration, startup, waiting, and cleanup are logically organized, with appropriate try/finally resource management. Nesting: Moderate nesting from the anonymous channel initializer and try/finally remains manageable. Clarity of intent: The class documentation and lifecycle comments clearly describe an SCTP echo server, but two always-false hexadecimal XOR checks introduce meaningless distractions; short names such as b and f are less descriptive. Code length: Mostly concise, though the redundant checks and commented-out logging statement add unnecessary clutter. Action granularity: Most lines contain a single action or configuration step, but the inline conditional-and-throw statements compress multiple elements onto one line. Reading flow: The fluent bootstrap chain and sequential lifecycle are natural to follow, while unindented checks disrupt formatting and visual continuity.
Run 3
Code Structure: Server setup, binding, waiting, and cleanup are logically organized, with resource shutdown in a finally block. Nesting: Mostly shallow, although the anonymous channel initializer adds moderate nesting. Clarity of intent: The class description, API calls, and comments clearly convey an SCTP echo server; however, two always-false hexadecimal XOR checks introduce pointless, confusing noise. Code length: Generally concise, but the redundant checks and commented-out logging statement add unnecessary content. Action granularity: Most statements perform one action, and the fluent configuration places each operation on its own line; the inline assertion blocks are exceptions. Reading flow: Execution follows a natural lifecycle, but unindented assertion checks interrupt the otherwise consistent formatting, and abbreviated variables such as b and f slightly reduce clarity.