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 mai(String[] arg) throws Exception {
EventLoopGroup gro = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
try {
ServerBootstrap b = new ServerBootstrap();
b.group(gro)
.channel(NioServerSocketChannel.class)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void init(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 {
gro.shutdownGracefully();
}
}
}
Run 1
The code has a clear logical structure with a standard Netty server setup pattern. It uses flat nesting with only one anonymous inner class, making the flow easy to follow. The intent is evident: a simple discard server that logs connections. The code is concise, with each meaningful action on its own line. Reading flow is natural, progressing from configuration to binding to shutdown. Minor deductions: the method name 'mai' is a typo (should be 'main'), variable names like 'gro' and 'b' are slightly cryptic ('group' and 'bootstrap' would be clearer), and the single-letter 'f' for ChannelFuture is less descriptive. These minor naming issues reduce readability slightly but don't significantly impact understanding.
Run 2
The code is mostly readable with clear structure: imports, constants, class definition, and main method are logically organized. The Netty server bootstrap pattern follows a natural flow, with comments explaining non-obvious operations. Nesting is minimal, limited to one anonymous inner class and try-finally block. However, several issues prevent a higher score: the main method is misspelled as 'mai', the EventLoopGroup variable is abbreviated to 'gro' which is unclear, and the inner class initialization could be replaced with a lambda for conciseness. The code length is appropriate for a server example, but the method name typo and abbreviated variables slightly obscure intent and reduce readability.
Run 3
The code is generally readable but has notable issues. Structure is logical with clear sections for setup, startup, and shutdown, though the handler variable name is misleading ('handler' is actually a shared UptimeServerHandler instance, not a generic handler). Nesting is minimal and acceptable - only one level deep in the ChannelInitializer. Intent is mostly clear from comments, but the typo 'mai' instead of 'main' breaks the entry point and would cause compilation failure. Variable names are inconsistent: 'b' for bootstrap and 'gro' for group are too abbreviated, while 'f' for future is conventional but still terse. Action granularity is good with one operation per line in the builder chain. The static final PORT parsed at class load time is a minor concern but acceptable. Overall, the code follows Netty patterns well but needs better naming and the critical typo fixed.
Run 1
Code Structure: Server configuration, binding, waiting, and cleanup are logically organized, with resource cleanup clearly placed in finally. Nesting: Mostly shallow, though the anonymous ChannelInitializer adds moderate nesting. Clarity of intent: Netty method names and lifecycle comments explain the purpose, but abbreviated variables (gro, b, f), the method name mai rather than main, and awkward class documentation reduce clarity. Code length: Concise overall, with only a slightly verbose shutdown comment. Action granularity: Statements generally perform one action, and the fluent configuration chain places each configuration step on its own line. Reading flow: Execution follows a natural setup-to-shutdown sequence, supported by consistent indentation and useful spacing; the lack of separation between the package declaration and imports is a minor formatting weakness.
Run 2
Code Structure: Logical organization separates configuration, server setup, connection handling, and cleanup. Nesting: The try/finally and anonymous initializer introduce moderate, manageable nesting. Clarity of intent: Netty APIs and comments make the server lifecycle clear, but abbreviated names such as gro, b, and f reduce clarity. The apparent typo mai instead of main obscures the intended entry point, and the discard behavior resides in an unseen handler. Code length: Concise overall, though the shutdown comment is slightly verbose. Action granularity: Most statements perform one logical action; the fluent configuration chain is clearly split across lines. Reading flow: Setup, binding, waiting, and cleanup follow a natural sequence, with consistent indentation. A blank line after the package declaration and more descriptive identifiers would improve readability.
Run 3
Code Structure: Logically organized into configuration, server setup, binding, waiting, and cleanup. Nesting: Limited to try/finally and an anonymous initializer, keeping complexity manageable. Clarity of intent: Netty APIs and comments communicate the server lifecycle, but abbreviated names such as gro, b, and f reduce clarity; mai appears to be a mistyped main entry point. Code length: Compact and mostly necessary, though the shutdown comment is somewhat verbose. Action granularity: Statements generally express one logical action, and the fluent configuration places each step on its own line. Reading flow: Execution follows a natural setup-to-cleanup sequence, with consistent indentation and useful spacing. Missing separation between the package declaration and imports, awkward documentation wording, and unconventional naming slightly weaken readability.