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;
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);
}
});
ChannelFuture f = b.bind(PORT).sync();
f.channel().closeFuture().sync();
} finally {
group.shutdownGracefully();
}
}
}
Run 1
The code is well-structured and readable. It follows standard Netty server patterns with clear separation of concerns. The structure is logical: configuration constants, private constructor, main method with proper resource management. Nesting is minimal and natural—only one anonymous inner class for channel initialization. The intent is clear: set up a Netty server on a configurable port. The code is concise without being obscure. Action granularity is good, with the builder-pattern chain clearly showing server configuration. Reading flow is natural: setup, bind, wait for close, shutdown. Minor deductions: the static handler instance might raise thread-safety questions without context, and the empty lines with stray spaces after the bind call are slightly untidy. The import section could be organized better. Overall, this is professional-grade, maintainable code.
Run 2
The code is generally readable with clear intent and logical structure. It follows a standard Netty server bootstrap pattern, and the main method is straightforward. Nesting is minimal, with only one anonymous inner class for channel initialization, which is idiomatic for Netty. The use of constants and a private constructor shows good organization. However, readability is slightly reduced by unnecessary blank lines between imports, a trailing empty comment line, and multiple consecutive empty lines after the bind call. These small formatting issues disrupt the reading flow. The code could also benefit from extracting a separate method for server bootstrap configuration to improve clarity, but the current length is acceptable. Action granularity is mostly one action per line, and the overall structure is flat and easy to follow. The main readability drawback is the inconsistent whitespace rather than the code logic itself.
Run 3
The code is well-structured and easy to follow. It has a clear single-purpose class, flat nesting (only one anonymous inner class), and logical organization with setup, binding, and shutdown phases. Naming is explicit (e.g., 'group', 'b', 'f' are conventional but slightly terse for Netty patterns). Each line generally performs one action, and the reading flow follows a natural top-to-bottom progression. The few blank lines and comments are harmless but not overbearing. Minor issues: the 'handler' static field and 'PORT' parsing at class level can obscure intent slightly, and the anonymous ChannelInitializer adds one level of nesting. Overall, the code is concise, idiomatic Netty, and highly readable for experienced Java developers.
Run 1
Code Structure: Logically organized into configuration, server initialization, binding, waiting, and cleanup. Nesting: Mostly shallow; the anonymous channel initializer adds modest, manageable nesting. Clarity of intent: Netty API calls clearly convey server setup and lifecycle, though variable names b and f are less descriptive than bootstrap and bindFuture. Code length: Concise, with no unnecessary logic, but excessive blank lines add visual clutter. Action granularity: Statements generally perform one coherent action; the fluent configuration chain is split across lines for readability. Reading flow: Execution proceeds naturally from setup to shutdown, and try/finally makes cleanup easy to identify. Overall, the code is highly readable, with minor naming and formatting weaknesses.
Run 2
Code Structure: Logically organized into configuration, server initialization, binding, waiting, and cleanup. Nesting: Mostly shallow, though the anonymous ChannelInitializer inside the fluent builder adds moderate nesting. Clarity of intent: Netty API calls make the server lifecycle clear, but variable names b and f are less descriptive than bootstrap and bindFuture. Code length: Concise overall, with unnecessary blank lines creating visual clutter. Action granularity: Statements generally perform one coherent action, and chained configuration calls are separated by line. Reading flow: Execution proceeds naturally from setup to shutdown, with try/finally clearly expressing resource cleanup; inconsistent whitespace slightly interrupts the flow.
Run 3
Code Structure: Logically organized into configuration, server setup, binding, waiting, and cleanup. Nesting: Mostly shallow, though the anonymous channel initializer adds moderate nesting inside the fluent configuration chain. Clarity of intent: Class and API names communicate the server's purpose clearly, but single-letter variables b and f are less descriptive. Code length: Concise overall, with unnecessary blank lines adding visual clutter. Action granularity: Statements generally perform one coherent action, and chained configuration calls are separated onto individual lines. Reading flow: Execution proceeds naturally from initialization through shutdown, with try/finally making resource cleanup easy to follow. More descriptive local variable names and consistent whitespace would improve readability.