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 a(String[] a) throws Exception {
EventLoopGroup c = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
try {
ServerBootstrap b = new ServerBootstrap();
b.group(c)
.channel(NioServerSocketChannel.class)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void b(SocketChannel d) {
d.pipeline().addLast(handler);
}
});
// Bind and start to accept incoming connections.
ChannelFuture e = 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.
e.channel().closeFuture().sync();
} finally {
c.shutdownGracefully();
}
}
}
Run 1
The code is heavily obfuscated. Parameters and local variables use single letters like 'a', 'b', 'c', 'd', 'e' instead of descriptive names (e.g., 'args', 'bootstrap', 'bossGroup', 'ch'), which destroys readability and intent. The method name 'a' and overridden method 'b' are meaningless. The structure is otherwise standard Netty bootstrap boilerplate, but the naming completely breaks reading flow and clarity. Nesting is shallow, and line granularity is acceptable, but concise length is negated by ambiguous naming. Comments are helpful but only partially offset the confusion. The code forces the reader to infer the role of each variable from context, making it unnecessarily difficult to understand.
Run 2
The code has a reasonable top-level structure (bootstrap configuration, try/finally for cleanup), but readability is severely undermined by poor naming and unclear intent. Method and variable names (a, b, c, d, e, b()) are meaningless, obscuring the purpose of each component. The ChannelInitializer's overridden method is also obfuscated (b(SocketChannel d)). Nesting is moderate—only one anonymous inner class—but the reading flow is disrupted by non-descriptive identifiers. Action granularity is mostly fine, with one operation per line, and the code is concise overall. However, clarity of intent suffers dramatically due to the single-letter naming convention, making it hard to follow without prior knowledge. Comments are helpful but cannot compensate for the cryptic identifiers. A refactoring with meaningful names (e.g., main, bossGroup, channelFuture) would significantly improve readability.
Run 3
The code has a logical structure with clear intent and reasonable length, but readability is significantly reduced by poor naming conventions. Methods 'a' and 'b' and variables 'c', 'b', 'd', 'e' are meaningless, obscuring what the code does despite helpful comments. The hierarchy is mostly flat with only one level of anonymous class nesting, and actions are generally one per line. Reading flow is disrupted by the terse parameter names and the unconventional method names, making the code harder to follow than necessary. If variable names were descriptive, the score would be much higher. Structure and error handling (try-finally for graceful shutdown) are sound, but the intentional obfuscation of names is a major readability issue.
Run 1
Code Structure: Logically separates configuration, server setup, connection handling, and cleanup using try/finally. Nesting: Moderate nesting from the anonymous initializer inside the try block, but still manageable. Clarity of intent: Netty API calls and comments explain the server lifecycle, but single-letter names (a, b, c, d, e) obscure roles. Naming the entry method a rather than main and the initializer method b rather than initChannel also creates confusion about intended execution and overriding. Code length: Concise overall, with slightly verbose shutdown comments. Action granularity: Statements generally express one action each, and the configuration chain places each step on its own line. Reading flow: Setup, bind, wait, and cleanup follow a natural sequence, though cryptic identifiers and the missing blank line after the package declaration reduce readability.
Run 2
Code Structure: Logically organized into configuration, server setup, connection handling, and cleanup, with a clear try/finally lifecycle. Nesting: Moderate nesting from the anonymous initializer within the bootstrap chain, but still manageable. Clarity of intent: Netty APIs and comments explain the server behavior, but single-letter names (a, b, c, d, e) obscure roles. The renamed entry method and initializer callback also conflict with expected Java/Netty conventions, making intent less trustworthy. Code length: Concise overall, with little unnecessary code, though the shutdown comment is somewhat verbose. Action granularity: Most statements perform one logical action; fluent chains combine related configuration steps in a readable way. Reading flow: Setup, bind, wait, and cleanup follow a natural sequence, but ambiguous identifiers and unconventional method names interrupt comprehension.
Run 3
Code Structure: Logically separates configuration, server setup, connection handling, and cleanup with try/finally. Nesting: Moderate nesting from the anonymous initializer within the configuration chain; manageable overall. Clarity of intent: Netty API calls and comments explain the server lifecycle, but single-letter names (a, b, c, d, e) obscure roles. The renamed entry-point and initializer methods also undermine recognizable Java/Netty conventions. Code length: Compact, with little unnecessary code, though the shutdown comment is somewhat verbose. Action granularity: Most statements represent a coherent action; fluent chains combine related setup operations in a readable way. Reading flow: Setup, bind, wait, and cleanup follow a natural sequence, but cryptic identifiers and limited whitespace around the package/import section reduce readability.