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.
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 well-structured, with a clear main method, proper try-finally resource handling, and a straightforward Netty server bootstrap pattern. Nesting is minimal—only an anonymous ChannelInitializer inner class—keeping the logic flat. Intent is clear: a simple server that discards messages, supported by a concise class comment. Code length is appropriate; there's no unnecessary duplication or verbosity. Each line generally performs one action, improving readability. The reading flow follows a natural setup-bind-wait sequence, with comments clarifying non-obvious points like the blocking sync calls. Minor deductions: the static PORT parsing and handler declaration could be grouped more logically, and the anonymous inner class adds slight friction compared to a lambda or named class. Overall, highly readable with only trivial improvements possible.
Run 2
The code is well-structured with clear separation of concerns: configuration, initialization, and lifecycle management. Nesting is minimal—only the anonymous ChannelInitializer adds a second level, used appropriately. Intent is evident from descriptive names and comments, making the server's purpose clear. Code length is concise and avoids unnecessary boilerplate. Action granularity is mostly one action per line, though chained builder calls combine multiple steps, which is idiomatic Netty style and still readable. Reading flow follows a natural top-down sequence: setup, bind, wait, shutdown. The main weakness is the static PORT initialization using System.getProperty, which is slightly less discoverable than a constructor parameter or config class. Overall, the code is very readable for developers familiar with Netty conventions.
Run 3
The code is well-structured with clear separation of concerns and follows standard Netty patterns. It has minimal nesting, clear intent through descriptive naming, and appropriate use of try-finally for resource cleanup. The main method flows logically: setup, configuration, binding, and shutdown. The anonymous inner class for ChannelInitializer adds slight complexity but is idiomatic Netty. Comments clarify the blocking behavior effectively. Overall, highly readable with minor room for improvement in extracting the channel initializer for testability.
Run 1
Code Structure: Logically organized into configuration, initialization, server startup, waiting, and cleanup. Nesting: Limited overall, although the anonymous ChannelInitializer adds indentation within the fluent configuration chain. Clarity of intent: Netty API names and comments explain the server lifecycle clearly; abbreviated variables b, f, and ch and awkward class documentation slightly weaken clarity. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one logical action, and fluent configuration calls are separated onto individual lines. Reading flow: Execution proceeds naturally from setup to binding, waiting, and graceful shutdown, with whitespace separating phases.
Run 2
Code Structure: Logically organized into configuration, server initialization, binding, waiting, and cleanup, with reliable resource cleanup in finally. Nesting: Mostly shallow; the anonymous channel initializer adds modest nesting without obscuring control flow. Clarity of intent: Netty API calls and lifecycle comments clearly communicate the server setup, but abbreviated names b, f, and ch reduce clarity, and the message-discarding behavior resides in an unseen handler. Code length: Concise and proportionate to its purpose, though the shutdown comment could be shorter. Action granularity: Most statements perform one coherent action, and the fluent configuration chain places each configuration step on its own line. Reading flow: Execution proceeds naturally from setup through shutdown, aided by consistent indentation and whitespace. Minor improvements include descriptive variable names and clearer introductory documentation.
Run 3
Code Structure: Logically organized into configuration, server setup, execution, and cleanup, with try/finally making resource management clear. Nesting: Mostly shallow, although the anonymous ChannelInitializer inside the fluent configuration adds a small nested section. Clarity of intent: Netty method names and comments explain the server lifecycle well; abbreviated variables b, f, and ch and the awkward class documentation slightly reduce clarity. Code length: Concise, with little unnecessary code, though the shutdown comment could be shorter. Action granularity: Statements generally perform one coherent action, and chained configuration calls occupy separate lines. Reading flow: Setup, binding, waiting, and cleanup follow a natural sequence, supported by consistent indentation and spacing.