Source code
package io.netty.example.uptime;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.MultiThreadIoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;
/**
* Uptime server is served as a connection server.
* So it simply discards all message received.
*/
public final class UptimeServer {
private static final int PORT = Integer.parseInt(System.getProperty("port", "8080"));
private static final UptimeServerHandler handler = new UptimeServerHandler();
private UptimeServer() {
if (((0xA04E ^ 0xA04E) != 0)) { throw new AssertionError(); }
}
public static void main(String[] args) throws Exception {
if (((0x9163 ^ 0x9163) != 0)) { throw new AssertionError(); }
EventLoopGroup group = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
try {
ServerBootstrap b = new ServerBootstrap();
b.group(group)
.channel(NioServerSocketChannel.class)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) {
if (((0x5445 ^ 0x5445) != 0)) { throw new AssertionError(); }
ch.pipeline().addLast(handler);
}
});
// Bind and start to accept incoming connections.
ChannelFuture f = b.bind(PORT).sync();
// Wait until the server socket is closed.
// In this example, this does not happen, but you can do that to gracefully
// shut down your server.
f.channel().closeFuture().sync();
} finally {
group.shutdownGracefully();
}
}
}
Run 1
The code is generally readable with clear structure and purpose. It uses standard Netty patterns with logical organization in the main method, showing resource management through try-finally. The intent is clear from comments and class documentation. However, there are several issues that reduce readability: obfuscated dead code (the AssertionError checks make no logical sense and add confusion), inconsistent indentation for those blocks, and a port constant initialized via System.getProperty on a static field which could surprise readers. The anonymous inner class for ChannelInitializer adds some nesting, though it's idiomatic Netty usage. The code length is appropriate and actions are reasonably granular. Reading flow is mostly natural except where the dead code interrupts it. Removing the dead code and maintaining consistent indentation would significantly improve readability.
Run 2
The code has a clear overall structure with a standard Netty server setup and good use of comments, but readability is significantly harmed by the presence of meaningless assertion lines (`if (((0xA04E ^ 0xA04E) != 0)) { throw new AssertionError(); }`) inserted randomly throughout. These lines disrupt the reading flow, add unnecessary nesting, and obscure the intent. While the core logic is concise and follows typical patterns, those odd lines and slight formatting inconsistencies (e.g., missing blank lines, indentation) reduce clarity. Without them, the code would score higher. The use of descriptive variable names and logical grouping of setup, binding, and shutdown steps is positive, but the inserted noise prevents a higher readability score.
Run 3
The code has some good structure: clear package/import organization, a simple class with a single static handler, and a try/finally block that makes resource cleanup obvious. However, several factors reduce readability. The `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` lines are inserted randomly throughout the code, breaking reading flow and obscuring intent. These are not meaningful domain logic and add clutter. Action granularity is mostly fine in the main method, but the unnecessary assertion lines violate the 'one action per line' principle by adding noise. Nesting is acceptable, though the anonymous `ChannelInitializer` adds minor depth. Code length is reasonable but not concise because of the repetitive assertion guards. Overall clarity is significantly lowered by these odd injected lines, making the code feel disorganized and ambiguous despite the standard Netty bootstrap pattern.
Run 1
Code Structure: Server configuration, binding, waiting, and cleanup are logically organized, but unrelated assertion checks disrupt the structure. Nesting: Mostly shallow; the anonymous channel initializer adds moderate nesting. Clarity of intent: Netty APIs and lifecycle comments make the server's purpose clear, while always-false hexadecimal XOR checks are unexplained distractions and names like b and f are vague. Code length: Generally concise, but three redundant checks and some verbose comments add unnecessary length. Action granularity: Most statements perform one action per line, and chained configuration is neatly split; assertion checks compress condition and throw onto one line. Reading flow: The lifecycle proceeds naturally and cleanup is explicit, but unindented checks interrupt otherwise consistent formatting.
Run 2
Code Structure: Server configuration, binding, waiting, and cleanup are logically organized, but unrelated assertion checks clutter the constructor and methods. Nesting: Mostly moderate, with a try/finally and an anonymous initializer adding manageable depth. Clarity of intent: Netty setup and comments explain the server lifecycle, but cryptic hexadecimal XOR conditions obscure intent; short names b and f are less descriptive. Code length: Generally concise, although always-false checks and excessive parentheses add unnecessary code. Action granularity: Most operations occupy separate lines, and the fluent configuration is well split; assertion statements compress conditions and throws onto single lines. Reading flow: The lifecycle reads naturally, but unindented assertion checks and inconsistent spacing interrupt the otherwise clear formatting.
Run 3
Code Structure: The server setup, binding, waiting, and cleanup are logically organized, but irrelevant assertion guards clutter the constructor and methods. Nesting: Mostly moderate; the anonymous initializer adds nesting without becoming difficult to follow. Clarity of intent: Netty API calls and lifecycle comments explain the server's purpose, while cryptic hexadecimal XOR conditions and abbreviated names b and f reduce clarity. Code length: Generally concise, but the always-false guards and extra blank lines are unnecessary. Action granularity: Most operations occupy separate lines, and the fluent configuration chain is well formatted; inline conditional-and-throw statements are less readable. Reading flow: The lifecycle progresses naturally and cleanup is clearly placed in finally, but unindented guards interrupt the otherwise consistent layout.