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 send(String[] user) throws Exception {
EventLoopGroup order = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
try {
ServerBootstrap age = new ServerBootstrap();
age.group(order)
.channel(NioServerSocketChannel.class)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void createScore(SocketChannel map) {
map.pipeline().addLast(handler);
}
});
// Bind and start to accept incoming connections.
ChannelFuture key = age.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.
key.channel().closeFuture().sync();
} finally {
order.shutdownGracefully();
}
}
}
Run 1
The code has a logical structure and flat nesting, which aids comprehension. However, clarity of intent is hampered by misleading names like 'send' for server startup, 'age' for ServerBootstrap, 'order' for EventLoopGroup, and 'createScore' for channel initialization. These choices obscure the purpose of variables and methods. Action granularity is mostly good with one operation per line, but the anonymous inner class adds conceptual nesting. Reading flow is moderately natural, with comments explaining the blocking behavior. The code length is concise but the obfuscated naming makes it feel longer than necessary. Overall structure and flow are adequate, but poor naming significantly reduces readability.
Run 2
The code is poorly named and confusing. Variables like 'order', 'age', 'key', 'user', and 'map' are semantically meaningless, obscuring intent. The method name 'send' does not describe starting a server, and 'createScore' does not indicate channel initialization. The structure is logical and flat, but clarity is severely compromised. Comments help somewhat, but the identifiers undermine readability. The code is concise, but the poor naming makes it hard to understand. Action granularity is mostly one action per line, but reading flow is unnatural due to misleading names. Overall, the code structure is acceptable but the lack of meaningful naming and inconsistent terminology significantly reduces readability.
Run 3
The code has extremely poor naming conventions that obscure intent: 'order', 'age', 'key', 'map', 'createScore', and 'send' are all misleading or irrelevant. The method signature 'send(String[] user)' takes an unused parameter and is poorly named for server startup logic. The class-level constant 'handler' violates naming conventions by not being uppercase. While the overall structure follows a standard Netty bootstrap pattern and nesting is acceptable, the obfuscated naming makes the code nearly unreadable despite being syntactically valid. The logic flow is linear and each action is on its own line, but the semantic content is buried under bad identifiers. Comments are helpful but cannot compensate for the pervasive naming issues.
Run 1
Code Structure: Logically organized into configuration, server setup, binding, waiting, and cleanup, with reliable resource cleanup in finally. Nesting: Moderate nesting from try/finally and an anonymous initializer, but still manageable. Clarity of intent: The largest weakness is misleading names such as send, user, order, age, map, and key, which obscure their roles. createScore also does not match the expected ChannelInitializer callback name, making the apparent intent confusing. Code length: Compact and largely necessary, though the shutdown comment is somewhat verbose. Action granularity: Statements generally perform one action, and the fluent configuration chain places each step on its own line. Reading flow: Execution proceeds naturally from initialization to shutdown, supported by comments, but arbitrary naming and minimal whitespace between the package and imports reduce readability.
Run 2
Code Structure: Server setup, binding, waiting, and cleanup are logically organized, with shutdown handled in finally. Nesting: Moderate nesting from try/finally and an anonymous initializer remains manageable. Clarity of intent: Netty APIs and comments reveal the server lifecycle, but names such as send, user, order, age, map, key, and createScore obscure their roles; the unused parameter adds confusion. Code length: Concise overall, with little unnecessary code, though the socket-close comment is verbose. Action granularity: Most statements perform one action; the fluent bootstrap chain combines configuration steps but places each on a separate line. Reading flow: Execution proceeds naturally from initialization to shutdown, supported by spacing and comments, but misleading identifiers interrupt comprehension.
Run 3
Code Structure: Setup, binding, waiting, and cleanup are logically organized, with shutdown clearly placed in finally. Nesting: Moderate nesting from try/finally and an anonymous initializer remains manageable. Clarity of intent: Server-related types and comments reveal the purpose, but names such as send, user, order, age, map, key, and createScore are misleading or uninformative. Code length: Concise overall, though the unused user parameter and verbose shutdown comment add noise. Action granularity: Most statements perform one coherent action; the fluent configuration chain is separated clearly across lines. Reading flow: Execution proceeds naturally from configuration to shutdown, but poor naming interrupts comprehension. The missing separation between the package declaration and imports slightly weakens formatting.