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 {
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.
// 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.
(b.bind(PORT).sync()).channel().closeFuture().sync();
} finally {
group.shutdownGracefully();
}
}
}
Run 1
The code is generally readable with a clear top-level structure: static constants, private constructor, and a main method with try-finally resource cleanup. The purpose is documented at the class level, and the fluent builder pattern is reasonable. However, readability is reduced by the anonymous ChannelInitializer inner class adding nesting, and the long chained expression `(b.bind(PORT).sync()).channel().closeFuture().sync()` packs multiple actions into one line with unclear intent—the parentheses and method chain disrupt reading flow. Additionally, there are stray blank comment lines that break natural flow and look like leftover placeholders. Naming is mostly clear, but `b` is too short for a ServerBootstrap variable. Overall, the logic is understandable, but improvements in line granularity, variable naming, and comment cleanliness would raise the score.
Run 2
The code is well-structured and readable overall. It follows standard Netty server setup patterns with clear imports and a logical flow. The class is concise, with a single main method and minimal nesting. The intent is understandable, and variable names like 'group' and 'b' are slightly terse but acceptable within the Netty context. Action granularity is mostly good, though the final bind/sync/closeFuture/sync chain is dense. The unused blank comment lines are minor clutter. Nesting is shallow, and the code is not overly long. Overall, it reads naturally and would be easy to maintain, losing points only for dense chained operations and placeholder comments.
Run 3
The code is well-structured with clear separation of concerns: constants, constructors, and main method. Nesting is minimal, limited to try-finally and an anonymous ChannelInitializer. Intent is clear through descriptive names and comments explaining server behavior. The code is concise without unnecessary verbosity. Action granularity is mostly one action per line, though the final bind/sync/closeFuture line combines multiple operations. Reading flow is natural, following setup, configuration, binding, and shutdown sequence. Minor deductions: the empty comment lines are slightly distracting, and the anonymous inner class could be a lambda for improved readability. Overall, very readable code following standard Netty patterns.
Run 1
Code Structure: Logically organized into configuration, server setup, execution, and cleanup, although binding and waiting are combined. Nesting: Moderate nesting from try/finally and an anonymous initializer remains manageable. Clarity of intent: Class naming, API calls, and comments convey the server's purpose; the abbreviated variable b and unused ChannelFuture import slightly reduce clarity. Code length: Concise overall, with minor clutter from redundant whitespace and comments. Action granularity: Most lines express one configuration step, but the final chained expression combines binding, synchronization, channel retrieval, and waiting for closure. Reading flow: Generally natural from setup to shutdown, though the separated binding comment and combined bind/wait expression interrupt the otherwise clear progression.
Run 2
Code Structure: Logically organized into configuration, server setup, execution, and cleanup, with reliable resource handling through try/finally. Nesting: Mostly shallow, although the anonymous ChannelInitializer adds indentation inside the fluent configuration chain. Clarity of intent: Netty APIs and comments communicate the server lifecycle, but the name b is vague, and message-discarding behavior resides in an unseen handler. Code length: Compact overall, with unnecessary blank lines and somewhat verbose shutdown commentary. Action granularity: Configuration operations occupy separate lines, but binding, synchronization, channel retrieval, and waiting for closure are combined into one dense expression. Reading flow: Generally follows a natural setup-to-cleanup sequence; the detached binding comment and extra parentheses around b.bind(PORT).sync() slightly interrupt readability.
Run 3
Code Structure: Logically organized into configuration, server initialization, and guaranteed cleanup using try/finally. Nesting: Mostly shallow, although the anonymous ChannelInitializer adds indentation within the fluent configuration chain. Clarity of intent: Netty API names communicate server setup clearly, but short names such as b and ch, awkward documentation, and the separated binding comment reduce clarity. Code length: Concise overall, with unnecessary blank lines and slightly verbose shutdown commentary. Action granularity: Configuration calls occupy separate lines, but binding, synchronization, channel access, and waiting for closure are compressed into one expression. Reading flow: Generally follows a natural setup-run-cleanup sequence; placing the binding operation beneath the waiting comments rather than its own comment slightly disrupts that flow.