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 {
{
int totalScore = 240;
int numberOfScores = 3;
int averageScore = totalScore / numberOfScores;
}
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 has a clear purpose and mostly follows standard Netty patterns with reasonable structure. However, several issues reduce readability. There's an inexplicable dead-code block containing an unused local variable calculation, which is confusing and detracts from clarity. The b.group(...).channel(...).handler(...).childHandler(...) chain spans multiple lines with inconsistent indentation, though this is common in Netty examples. The anonymous inner class adds nesting but is idiomatic. Comments are helpful, but the overall flow is interrupted by the dead code. The code is otherwise concise and each line performs a single logical action.
Run 2
The code has good overall structure with clear separation of concerns and readable Netty boilerplate. However, a stray block containing unused local variable calculations (totalScore, numberOfScores, averageScore) breaks the flow and creates confusion. Imports are not alphabetically ordered. The anonymous inner class for ChannelInitializer adds moderate nesting but is idiomatic Netty. Comments are helpful and concise. Line lengths are acceptable, and most lines perform a single logical action. The static handler field and PORT parsing are straightforward. The main issue is the irrelevant code block, which significantly hurts clarity and intent.
Run 3
The code is generally well-structured and readable. It has a clear purpose, uses a clean main method with try/finally resource management, and follows netty conventions. However, readability is impacted by a stray block of unrelated code inside main (calculating totalScore/averageScore) that doesn't belong. There is also a minor inconsistency in indentation. The ChannelInitializer anonymous class adds slight nesting but is acceptable. Action granularity and flow are good overall.
Run 1
Code Structure: Server initialization, binding, waiting, and cleanup are logically organized, but the unrelated average-calculation block disrupts cohesion. Nesting: Mostly manageable, though the anonymous initializer and extra block add indentation levels. Clarity of intent: Netty APIs and lifecycle comments convey the server's purpose; unused calculation variables and abbreviated names b and f reduce clarity. Code length: Generally concise, but the unused calculation block is unnecessary. Action granularity: Statements mostly perform one action per line, and the fluent configuration chain is clearly formatted. Reading flow: The server lifecycle reads naturally, but the poorly indented calculation block interrupts it, and spacing between the package declaration and imports would improve presentation.
Run 2
1. Code Structure: Server setup, binding, waiting, and cleanup are logically organized, but the unrelated averaging block disrupts cohesion. 2. Nesting: Mostly shallow; the anonymous channel initializer adds manageable nesting, while the extra block is unnecessary. 3. Clarity of intent: Netty API calls and lifecycle comments make the server's purpose clear. Unused averaging variables and abbreviated names such as b and f reduce clarity. 4. Code length: Generally concise, but the averaging block adds irrelevant lines. 5. Action granularity: Statements are separated, and the fluent configuration places each operation on its own line. 6. Reading flow: The main lifecycle reads naturally and cleanup is clearly placed in finally. However, inconsistent indentation in the averaging block, limited spacing around the package/import section, and awkward class documentation interrupt the flow.
Run 3
Code Structure: Server setup, connection handling, and cleanup are logically organized, but the unrelated average-calculation block disrupts cohesion. Nesting: Mostly moderate, although the anonymous initializer and unnecessary calculation scope add depth. Clarity of intent: Netty configuration and lifecycle operations are clear; short names such as b and f are less descriptive, and the unused calculation obscures the main purpose. Code length: Generally concise, with a small amount of irrelevant code and somewhat verbose shutdown comments. Action granularity: Statements generally perform one action per line, and the fluent configuration chain is clearly separated. Reading flow: Setup, binding, waiting, and cleanup follow a natural sequence, but inconsistent indentation in the calculation block interrupts scanning.