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 generally clear and well-structured. Imports are organized, the class has a clear purpose with a Javadoc comment, and key methods like main() follow a logical flow. Nesting is minimal—only one anonymous inner class is used, which is standard Netty style and not overly complex. Intent is evident: configure a server, bind to a port, and wait for shutdown. Code length is appropriate, though a few lines (e.g., b.group().channel().handler().childHandler()) chain multiple actions, slightly reducing granularity. Reading flow is natural, aided by meaningful comments explaining the bind and blocking behavior. Minor deductions: the static handler field could be explained, and the anonymous ChannelInitializer adds a small amount of nesting, but overall the code is highly readable.
Run 3
The code is well-structured and follows clean coding practices. Imports are organized logically, and the class has a clear single responsibility. Nesting is minimal, with only one anonymous inner class for channel initialization. Variable and method names clearly express intent (e.g., 'group', 'bootstrap', 'shutdownGracefully'). The code is concise—no unnecessary boilerplate or duplication. Each action (group assignment, bootstrap configuration, binding, syncing) is on its own line or grouped logically, maintaining one-action-per-line granularity. Reading flow is natural: setup, try-finally resource cleanup, bind, then wait for shutdown. Comments explain non-obvious behavior without being excessive. Minor deductions: the anonymous ChannelInitializer could be replaced with a lambda for slightly better readability, and the static 'handler' is shared across channels, which is implicit but not obvious. Overall, highly readable Netty server code.
Run 1
Code Structure: Logically organized into configuration, server setup, connection handling, and cleanup; try/finally clearly separates lifecycle responsibilities. Nesting: Mostly shallow, though the anonymous ChannelInitializer adds moderate nesting within the fluent configuration. Clarity of intent: Netty API calls and lifecycle comments explain the purpose well, but abbreviated names b, f, and ch and awkward class documentation reduce clarity. Code length: Compact and appropriate, with little unnecessary code; the shutdown comment could be shorter. Action granularity: Statements generally perform one logical action, and fluent configuration places each setup step on its own line. Reading flow: Execution proceeds naturally from initialization through binding, waiting, and shutdown. Consistent indentation helps, although spacing between the package declaration and imports would improve visual organization.
Run 2
Code Structure: Logically organized into configuration, server setup, connection handling, execution, and cleanup. Nesting: Mostly shallow, though the anonymous ChannelInitializer inside the fluent configuration adds some visual depth. Clarity of intent: Netty API calls and lifecycle comments make the purpose clear, but abbreviated names such as b, f, and ch are less descriptive, and the introductory documentation is awkwardly phrased. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Statements generally express one logical action, and chained configuration calls are placed on separate lines for easy scanning. Reading flow: Naturally progresses from initialization to binding, waiting, and shutdown; consistent indentation helps. More descriptive local names and clearer introductory documentation would improve readability.
Run 3
Code Structure: Logically organized into configuration, server setup, binding, waiting, and cleanup; try/finally makes resource management clear. Nesting: Mostly shallow, although the anonymous ChannelInitializer adds a modest nesting level. Clarity of intent: Netty API names and lifecycle comments explain the server's purpose, but abbreviated variables b, f, and ch and awkward class documentation reduce clarity. Code length: Concise and appropriate for a small server example, with little unnecessary code. Action granularity: Statements generally perform one clear action, and the fluent configuration chain places each operation on its own line. Reading flow: Execution follows a natural setup-to-shutdown sequence with consistent indentation and useful spacing. More descriptive variable names and clearer introductory documentation would improve readability.