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() {
}
public static void main(String[] args) throws Exception {
{int lI0O_f4c1f49c=0xA67C^0xA67C;if(lI0O_f4c1f49c!=0){if(((lI0O_f4c1f49c|1)&1)==0){lI0O_f4c1f49c++;}else{lI0O_f4c1f49c--;}}}
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) {
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 imports, a simple server setup, and helpful comments explaining the bind and shutdown logic. However, there is a random dead-code block inserted at the start of the main method that severely damages clarity, has no purpose, and would be confusing to maintain. The rest of the structure is flat and well-organized, using a clear try/finally for resource cleanup and a standard Netty bootstrap chain. The anonymous inner class for ChannelInitializer adds slight verbosity but is acceptable for this pattern. The single static handler at the top is straightforward but not immediately obvious until it is used later. Overall length is appropriate, and the reading flow is natural except for the dead code, which lowers the score significantly.
Run 2
The code is generally readable with a clear logical structure, good variable names, and appropriate comments. However, it contains a significant readability issue: an obfuscated dummy line (lI0O_f4c1f49c...) that serves no purpose and is highly confusing. The code is mostly flat, with the only nesting in the anonymous ChannelInitializer class, which is acceptable. Intent is clear — a simple discard server — and the code is concise. Action granularity is mostly one action per line, though the bootstrap configuration chains method calls across multiple lines, which is idiomatic Netty style and actually improves readability. Reading flow is natural, following a typical server setup pattern. Deductions are mainly for the obfuscated line and minor chaining.
Run 3
The code is generally understandable but contains a significant readability issue: an obfuscated variable declaration with a no-op conditional block (lI0O_f4c1f49c) that serves no functional purpose and severely disrupts reading flow. Structure is otherwise logical with clear separation of concerns, minimal nesting, and concise method bodies. However, the obfuscated code violates clarity of intent and action granularity. The try-finally block is well-structured, and comments are helpful. Removing the obfuscated line would improve the score to around 16. The ChannelInitializer anonymous class adds moderate complexity but is acceptable given the Netty API conventions.
Run 1
Code Structure: The server setup, connection handling, and cleanup are logically organized, but an unrelated obfuscated block disrupts the structure. Nesting: Most nesting is moderate and conventional; the injected block adds unnecessary nested conditionals. Clarity of intent: Netty APIs and comments make the server lifecycle clear, while the opaque variable name and pointless bitwise operations obscure intent. Code length: The implementation is reasonably concise except for the redundant block. Action granularity: Most statements perform one action per line, but the injected block compresses declarations, conditions, and mutations onto one line. Reading flow: Configuration, binding, waiting, and shutdown follow a natural sequence, interrupted sharply by the unformatted block. Short names such as b and f also slightly reduce readability.
Run 2
Code Structure: The server setup, binding, waiting, and cleanup are logically organized, but an unrelated obfuscated block disrupts the structure. Nesting: Most code has manageable nesting; the injected block adds unnecessary nested conditionals. Clarity of intent: Netty configuration and lifecycle management are clear, aided by comments, while the cryptic variable and hexadecimal operations obscure a pointless computation. Code length: The server implementation is reasonably concise, but the no-op block adds needless code. Action granularity: Most statements are separated clearly, whereas the injected block compresses declarations, conditions, and mutations onto one line. Reading flow: The main server logic flows naturally, and the finally block makes cleanup easy to locate; inconsistent formatting and the unexplained block interrupt that flow.
Run 3
Code Structure: The server setup, binding, waiting, and cleanup are logically organized, but an unrelated obfuscated block disrupts main. Nesting: Most nesting is reasonable for Netty initialization and try/finally; the injected block adds unnecessary nested conditionals. Clarity of intent: API calls and comments explain the server lifecycle, while the cryptic variable and redundant bitwise operations obscure a no-op. Code length: The functional implementation is concise, but the injected block adds needless code. Action granularity: Most statements occupy separate lines; the obfuscated block compresses declarations, conditions, and mutations onto one line. Reading flow: Fluent configuration and orderly cleanup read naturally, but the unindented block interrupts the flow, and abbreviated names such as b and f slightly reduce clarity.