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 generally well-structured and readable. It follows standard Netty server bootstrap patterns with clear separation of concerns. The class has a single responsibility, proper encapsulation with a private constructor, and logical grouping of imports. The main method has a clear flow: setup, bind, wait, cleanup. Nesting is minimal—only one anonymous inner class with a one-line method. The intent is clear through descriptive naming and helpful comments. Code length is appropriate for a server bootstrap example. Each line performs a distinct action, especially in the fluent configuration chain. Reading flow is natural, moving from configuration to execution to shutdown. Minor deductions: the static handler field could be explained, and the anonymous inner class could be a lambda for brevity, but these don't significantly impact readability.
Run 2
The code is well-structured, with clear separation of concerns: imports, constants, private constructor, and main method. Nesting is minimal, limited to a try-finally block and an anonymous ChannelInitializer with clear purpose. Intent is evident from class and method names, plus concise comments explaining server behavior. Code length is appropriate—no unnecessary verbosity. Action granularity is strong, with bootstrap configuration chained cleanly across lines and one logical operation per line. Reading flow is natural, moving from setup to bind to shutdown, and the comments guide the reader without clutter. Minor deductions for the optional use of a lambda instead of an anonymous class and for not extracting the bootstrap configuration into a helper method, which could improve modularity, but overall readability is high.
Run 3
The code is well-structured with clear separation of concerns: imports, class-level constants, private constructor, and a concise main method. Nesting is minimal, with only a single anonymous inner class for channel initialization. Intent is clear from the class Javadoc and inline comments explaining bind and shutdown behavior. The code is concise, avoiding unnecessary boilerplate. Action granularity is generally one action per line, though the fluent ServerBootstrap chain combines multiple configuration steps in a concise, readable manner. Reading flow is natural: setup, bind, wait for closure, and graceful shutdown. Minor deductions: the pipeline addition within the anonymous class could be slightly more explicit, and the static handler instance might raise state-sharing concerns, but these do not significantly impact readability.
Run 1
Code Structure: Logically separates configuration, initialization, binding, waiting, and cleanup. Nesting: Mostly shallow; the anonymous ChannelInitializer adds modest nesting within the fluent configuration chain. Clarity of intent: Netty API calls and lifecycle comments make the server's purpose clear, but abbreviated names b, f, and ch reduce clarity, and the class documentation is awkwardly worded. Code length: Compact and appropriate for a minimal server, with little unnecessary code. Action granularity: Statements generally perform one logical action; chained calls combine related configuration or synchronization steps without excessive density. Reading flow: Execution proceeds naturally from setup through shutdown, with consistent indentation and useful blank lines. A blank line after the package declaration and more descriptive variable names would improve readability.
Run 2
Code Structure: Logically organized into configuration, initialization, binding, waiting, and cleanup, with try/finally clearly managing resources. Nesting: Mostly shallow; the anonymous channel initializer adds moderate nesting but remains easy to follow. Clarity of intent: Netty API names and lifecycle comments communicate the server's purpose, though abbreviated variables b, f, and ch and awkward class documentation reduce clarity. Code length: Concise, with little unnecessary code; the shutdown comment could be shorter. Action granularity: Statements generally perform one logical action, and bootstrap configuration calls are separated across lines, making the fluent chain readable. Reading flow: Execution proceeds naturally from setup to shutdown, with consistent indentation and useful spacing. Understanding message discarding requires inspecting the external handler, but the overall server lifecycle is clear.
Run 3
Code Structure: Logically organized into configuration, server initialization, binding, waiting, and cleanup, with resource shutdown clearly placed in finally. Nesting: Mostly shallow; the anonymous ChannelInitializer adds modest nesting but remains easy to follow. Clarity of intent: Netty API calls and lifecycle comments explain the server's purpose, though abbreviated names b, f, and ch reduce clarity, and message-discarding behavior resides in an unseen handler. Code length: Concise, with little unnecessary code; the shutdown comment could be shorter. Action granularity: Generally one operation per line, with the fluent configuration chain formatted clearly. Reading flow: Execution proceeds naturally from setup to shutdown, aided by consistent indentation and whitespace. Minor weaknesses include awkward class documentation and the lack of separation between the package declaration and imports.