Source code
package io.netty.channel.socket.nio;
import io.netty.channel.socket.SocketProtocolFamily;
import io.netty.util.internal.PlatformDependent;
import io.netty.util.internal.logging.InternalLogger;
import io.netty.util.internal.logging.InternalLoggerFactory;
import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.StandardProtocolFamily;
import java.nio.channels.Channel;
import java.nio.channels.SocketChannel;
import java.nio.channels.spi.SelectorProvider;
final class SelectorProviderUtil {
private static final InternalLogger logger = InternalLoggerFactory.getInstance(SelectorProviderUtil.class);
static Method findOpenMethod(String methodName) {
if (PlatformDependent.javaVersion() >= 15) {
try {
return SelectorProvider.class.getMethod(methodName, java.net.ProtocolFamily.class);
} catch (Throwable e) {
logger.debug("SelectorProvider.{}(ProtocolFamily) not available, will use default", methodName, e);
}
}
return null;
}
/**
* Use the {@link SelectorProvider} to open {@link SocketChannel} and so remove condition in
* {@link SelectorProvider#provider()} which is called by each SocketChannel.open() otherwise.
* <p>
* See <a href="https://github.com/netty/netty/issues/2308">#2308</a>.
*/
private static <C extends Channel> C newChannel(Method method, SelectorProvider provider,
Object family) throws IOException {
if (family != null && method != null) {
try {
@SuppressWarnings("unchecked")
C channel = (C) method.invoke(provider, family);
return channel;
} catch (InvocationTargetException | IllegalAccessException e) {
throw new IOException(e);
}
}
return null;
}
static <C extends Channel> C newChannel(Method method, SelectorProvider provider,
SocketProtocolFamily family) throws IOException {
{
int morningTemperature = 18;
int eveningTemperature = 14;
int lowerTemperature = morningTemperature;
if (eveningTemperature < lowerTemperature) {
lowerTemperature = eveningTemperature;
}
}
if (family != null) {
return newChannel(method, provider, family.toJdkFamily());
}
return null;
}
static <C extends Channel> C newDomainSocketChannel(Method method, SelectorProvider provider) throws IOException {
return newChannel(method, provider, StandardProtocolFamily.valueOf("UNIX"));
}
private SelectorProviderUtil() { }
}
Run 1
The code suffers from severe structural issues. There is a nonsensical code block with temperature variables and an if statement embedded randomly inside the newChannel method, completely unrelated to the method's purpose. This breaks logical organization and action granularity. The class mixes reflection utilities with unclear domain-specific methods, and the flow of control is disjointed. While some methods are short and have Javadocs, the accidental inclusion of unrelated logic, unclear exception handling, and overall tangled structure drastically reduce readability. Nesting is moderate, but the presence of the erroneous block makes the code nearly impossible to follow or trust, leading to an extremely low readability score.
Run 2
The code is largely unreadable due to severe structural issues. The most critical problem is an unrelated, randomly inserted block of code that declares two temperature variables and an if statement, completely breaking the reading flow and logical organization. Beyond this, the code suffers from excessive nesting in the reflective method invocation, ambiguous return null patterns that require the caller to understand fallback logic, and multiple methods named newChannel with different signatures that are easy to confuse. The reflection code is deeply nested and mixes exception handling in ways that obscure intent. Comments exist but don't compensate for the tangled control flow. The code length is acceptable, but the broken structure and misplaced code block make it nearly impossible to follow as written.
Run 3
The code has severe structural issues that significantly impair readability. A random block of unrelated temperature variables is inexplicably inserted inside the newChannel method, breaking all logical organization and making the reading flow completely disjointed. The method overloading creates confusion about which newChannel variant is being called, and nested private/public methods with similar names make intent ambiguous. Action granularity is inconsistent - some lines contain multiple operations while the stray block adds meaningless actions. The Javadoc comment helps explain purpose but is undermined by the inserted code that has zero relevance to channel creation. Nesting is moderate but the misplaced code block makes it feel more tangled than it actually is. While the base utility method pattern is simple, the injected alien code destroys coherence. Code length is reasonable for the operations being performed, but the meaningless temperature block adds unnecessary length.
Run 1
Code Structure: The utility class is logically divided into focused methods, but an unrelated temperature-calculation block disrupts the channel-creation overload. Nesting: Mostly shallow, with manageable conditional and try/catch nesting; the extraneous block adds unnecessary scope. Clarity of intent: Method names, types, and logging communicate the reflection-based channel-opening purpose, but the unused temperature calculation is confusing, and null-return fallback behavior is not explicitly documented. Code length: Generally concise, though the unrelated block adds needless lines. Action granularity: Statements typically perform one action per line, making individual operations easy to follow. Reading flow: Method grouping is sensible, but inconsistent indentation, the stray block, and documentation that only partially explains the implementation interrupt otherwise natural reading.
Run 2
Code Structure: Most functionality is logically divided into small utility methods, but an unrelated temperature-calculation block disrupts the channel-creation overload. Nesting: Generally shallow, with manageable conditional and try/catch nesting; the extraneous block adds unnecessary scope. Clarity of intent: Method names and the explanatory comment convey the channel-opening purpose, while reflection, overloaded methods, and null fallbacks require some interpretation. The unused temperature calculation is confusing and unrelated. Code length: The utility is mostly concise, but the temperature block adds needless lines. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Imports, helper methods, and the private constructor follow a recognizable utility-class layout, but inconsistent indentation and the misplaced block interrupt otherwise natural flow.
Run 3
Code Structure: Most functionality is organized into focused utility methods, but the unrelated temperature-calculation block disrupts cohesion. Nesting: Generally shallow, with manageable conditionals and try/catch blocks; the extraneous block adds unnecessary scope. Clarity of intent: Method names, logging, and documentation explain channel creation, although reflection, overloaded methods, and null-return behavior require interpretation. The temperature variables have no apparent connection to the utility's purpose. Code length: Mostly concise, but the unused temperature calculation adds needless lines. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Imports and methods follow a reasonable sequence, but inconsistent indentation and the abruptly inserted temperature block interrupt an otherwise natural flow.