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 and readable. It has clear separation of concerns with a private constructor, a main method, and a separate handler class. Nesting is minimal, with only one anonymous inner class for channel initialization. The purpose is evident from the Javadoc comment and method names. The code is concise without unnecessary repetition. Most lines perform a single logical action, especially in the bootstrap configuration chain. The reading flow is natural: setup, bind, then wait for shutdown. Minor deductions: the static handler field could be a local variable or instance field for better testability, and the comment block is slightly verbose, but overall this is very clean Netty boilerplate code.
Run 3
The code is well-structured and highly readable. It follows a clear logical organization with a standard main method setup. Nesting is minimal, with only an anonymous ChannelInitializer class adding one level. The intent is explicit: a simple uptime server that discards messages, documented in a class-level comment. Code length is concise and avoids unnecessary verbosity. Each action is on its own line, improving clarity. The reading flow is natural, progressing from configuration to binding to shutdown. Minor deductions: the anonymous inner class could be replaced with a lambda for brevity, though this is a style choice. Overall, the code exemplifies clean, maintainable Netty boilerplate.
Run 1
Code Structure: Clearly organized into configuration, server setup, execution, and cleanup. Nesting: Shallow overall, though the anonymous channel initializer adds a small nested block within the configuration chain. Clarity of intent: Netty API calls and lifecycle comments make the server's purpose clear; abbreviated names b and f and the awkward class documentation slightly reduce clarity. Code length: Compact without unnecessary logic or duplication. Action granularity: Statements generally perform one logical action, and chained configuration calls are separated onto individual lines. Reading flow: Execution proceeds naturally from initialization through binding and waiting to guaranteed cleanup in finally. Minor spacing improvements around imports and more descriptive local variable names would improve readability further.
Run 2
Code Structure: Logically separates constants, construction prevention, server configuration, execution, and cleanup. Nesting: Mostly shallow, with modest additional nesting from the anonymous channel initializer inside try/finally. Clarity of intent: Netty API calls and lifecycle comments clearly convey the server's purpose, though abbreviated variables b, f, and ch and awkward class documentation reduce clarity slightly. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Statements generally perform one logical action; the fluent configuration chain places each configuration step on its own line. Reading flow: Follows a natural setup, bind, wait, and cleanup sequence, supported by consistent indentation and spacing.
Run 3
Code Structure: Logically organized into configuration, initialization, server startup, waiting, and cleanup. Nesting: Mostly shallow, though the anonymous ChannelInitializer inside the fluent configuration adds some depth. Clarity of intent: Netty API calls and lifecycle comments make the purpose clear, but abbreviated names b, f, and ch reduce clarity, and the class documentation is awkwardly worded. Code length: Concise, with little unnecessary code; the shutdown comment could be shorter. Action granularity: Most statements perform one logical action, and each bootstrap configuration step occupies its own line. Reading flow: The sequence follows the server lifecycle naturally, with try/finally clearly separating operation from cleanup. More descriptive local names and polished documentation would improve readability.