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))) {} else {
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))) {} else {
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 {
if (!((family != null))) {} else {
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 has reasonable structure and mostly flat nesting, but readability is hurt by inverted conditionals with empty if blocks (e.g., `if (!(...)) {} else { ... }`), which obscure intent and disrupt natural reading flow. Method names are clear, and action granularity is mostly one action per line, but unnecessary return-null fallbacks and duplicated null checks add length and ambiguity. The reflective logic is inherently complex, but clearer conditionals and comments would improve clarity.
Run 2
This code is difficult to read due to inverted conditional logic with empty if blocks and code in else branches, which obscures intent. Lines like `if (!((PlatformDependent.javaVersion() >= 15))) {} else {` force readers to mentally invert conditions, hurting flow. Nesting is moderate but awkward. The method `findOpenMethod` is reasonably short, but lack of early returns adds noise. Action granularity is mostly clear, but the conditional constructs combine multiple actions logically into one confusing statement. Comments exist but are not sufficient to offset the structural problems. Overall, the style is verbose, non-idiomatic, and forces extra cognitive effort.
Run 3
The code has several readability issues. The inverted if-else conditions with empty if blocks (`if (!(...)) {} else { ... }`) are confusing and should be positive conditions with early returns. This pattern appears three times creating unnecessary nesting and obscuring intent. The first method `findOpenMethod` has a redundant PlatformDependent version check with empty block. Method overloading creates ambiguity between `newChannel` variants. The `newDomainSocketChannel` method uses reflection to create a UNIX socket via `valueOf` which is non-obvious. The unused SuppressWarnings annotation adds noise. The private constructor at the end is good practice but misplaced after methods. While methods are relatively short and each performs one action per line, the control flow is convoluted. Comments are helpful but the code structure itself is tangled. Overall, it reads like decompiled or poorly refactored code requiring significant mental effort to understand the logic flow.
Run 1
Code Structure: The utility class is logically organized into focused methods, with a private constructor and centralized reflective channel creation. Nesting: Nesting is moderate, but empty if branches followed by else blocks add unnecessary complexity. Clarity of intent: Method names, types, and documentation generally communicate purpose; negated conditions with redundant parentheses obscure straightforward null and version checks. Code length: The code is reasonably concise, although awkward conditionals and repeated null-return patterns add avoidable noise. Action granularity: Most lines perform one action, making individual operations easy to follow. Reading flow: Imports, helper methods, and exception handling follow familiar Java conventions, but inconsistent parameter indentation and unnatural conditional structure interrupt the flow. Positive checks or early returns would substantially improve readability.
Run 2
Code Structure: A small, cohesive utility class with logically separated methods, although overloaded methods require some cross-reading. Nesting: Generally shallow, but empty if branches followed by else blocks add unnecessary nesting. Clarity of intent: Descriptive names, logging, and documentation explain the purpose; negated conditions with redundant parentheses obscure straightforward checks. Code length: Mostly concise, though empty branches and a temporary return variable add avoidable verbosity. Action granularity: Statements generally perform one action per line; compact empty branches slightly weaken consistency. Reading flow: Methods follow a sensible progression from method discovery to channel creation, but inverted conditions, uneven parameter indentation, and the lack of spacing after the package declaration interrupt otherwise natural reading.
Run 3
Code Structure: Cohesive utility class with small, logically separated methods, though overloaded newChannel methods require some tracing. Nesting: Mostly shallow, but empty if branches followed by else blocks add unnecessary nesting. Clarity of intent: Descriptive names, types, logging, and documentation explain the purpose; redundant parentheses and negated conditions obscure otherwise simple checks. Code length: Generally concise, with avoidable conditional boilerplate and a temporary variable. Action granularity: Statements mostly perform one action per line, although inline empty branches reduce visual clarity. Reading flow: Method organization is reasonable, but inverted conditions, empty blocks, and inconsistent parameter indentation interrupt natural reading.