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 readable for experienced Netty developers but suffers from formatting inconsistencies and nesting. Structure is logical, with clear setup of server bootstrap and lifecycle, while the single-purpose UptimeServer class is concise. However, import statements are jammed together, and method chaining is crammed onto single lines, harming scanability. The ChannelInitializer adds moderate nesting, though it’s a typical Netty pattern. Intent is mostly clear, with comments clarifying shutdown behavior, but inline anonymous class declaration is dense. Action granularity is acceptable despite chained configuration. Reading flow is uneven: static field initialization is compact, but the bootstrap chain and malformed line breaks disturb natural reading. Overall, the code is functional but would benefit from proper formatting, spacing, and broken-out configuration statements to achieve higher readability.
Run 2
The code has severe readability issues despite having a clear purpose. The package declaration, imports, and class definition are crammed onto single lines, making the header difficult to parse. The builder pattern is split awkwardly across lines with inconsistent indentation. The anonymous inner class is compressed onto one line containing multiple actions. The main method has only one try-finally nesting level, but the formatting obscures this. The logic itself is straightforward, but the formatting undermines clarity. Issues include: multiple statements per line, inconsistent spacing around dots and braces, poor indentation, and lack of visual separation between sections. The fluent API calls would benefit from consistent one-call-per-line formatting. The code would be significantly more readable with standard Java formatting conventions, proper line breaks after semicolons and opening braces, and consistent indentation.
Run 3
The code has a clear purpose and basic structure but suffers from formatting and organization issues. The single-line imports and method signatures reduce readability significantly. The nested ChannelInitializer with its inline override creates unnecessary nesting and breaks the natural flow. While the action granularity is mostly reasonable and comments help explain intent, the compressed layout makes the code harder to scan. Method chaining for server bootstrap configuration is acceptable but could be better formatted. Overall, it's functional and understandable but lacks the clean formatting and logical separation that would make it highly readable.
Run 1
Code Structure: The class logically separates configuration, startup, channel initialization, and cleanup, but compressed formatting obscures these sections. Nesting: Depth is moderate, with a try/finally and anonymous initializer; neither is excessive. Clarity of intent: The class name, Netty APIs, and lifecycle comments convey the server's purpose, though variable names b and f are vague and the introductory comment is awkward. Code length: The implementation is concise without substantial unnecessary code. Action granularity: Multiple imports, field declarations, and control-flow elements share lines, making individual actions harder to distinguish. Reading flow: The startup-to-shutdown sequence is natural, but crowded method chaining, inconsistent indentation, and inline braces interrupt scanning.
Run 2
Code Structure: The class follows a logical setup, bind, wait, and cleanup sequence, but compressed formatting obscures its organization. Nesting: Moderate nesting through try/finally and an anonymous channel initializer is appropriate, though awkward indentation makes it harder to follow. Clarity of intent: Netty API calls and comments explain the server lifecycle, but abbreviated names such as b and f reduce clarity. Code length: The implementation is reasonably concise without significant unnecessary logic. Action granularity: Multiple imports, field declarations, and control-flow statements share lines, making individual actions harder to distinguish. Reading flow: The overall execution order is natural, but crowded method chaining, inline annotations, and inconsistent line breaks interrupt scanning.
Run 3
Code Structure: The server follows a logical setup, bind, wait, and cleanup sequence, but compressed formatting obscures these sections. Nesting: Depth is moderate and justified by try/finally and the anonymous channel initializer. Clarity of intent: Netty API calls and lifecycle comments communicate the purpose, although names such as b and f are terse and the class documentation is awkward. Code length: The implementation is appropriately concise, with little unnecessary logic. Action granularity: Multiple imports, field declarations, and control-flow elements share lines, making distinct actions harder to identify. Reading flow: Inconsistent indentation, crowded method chaining, and inline braces interrupt an otherwise natural execution order. Conventional formatting and more descriptive local names would substantially improve readability.