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) {
final int a = 7;
final int b = 8;
if (PlatformDependent.javaVersion() >= (a + b)) {
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 {
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 has a simple, mostly clear structure with method delegations, but has several readability issues. The variable names 'a' and 'b' are meaningless; the constant '15' should be named (e.g., JAVA_VERSION_WITH_PROTOCOL_FAMILY). The method name 'findOpenMethod' is confusing because it returns a Method object rather than opening anything, so 'findSelectorProviderMethod' would be clearer. The nested `if (family != null && method != null)` adds minor nesting but is acceptable. Action granularity is reasonable, though the null-return pattern for error/missing cases is not immediately obvious and forces readers to trace call hierarchies. Mixed method ordering (private helper placed between public methods) breaks natural reading flow. Comments are useful but the factory method naming ('newChannel') and generic casting could be simplified to improve clarity without excessive length.
Run 2
The code is generally readable due to clear method names, concise helpers, and flat structure with minimal nesting. However, some issues reduce clarity: the odd 'a' and 'b' constants obscure the java version check, and the overloaded newChannel methods have nuanced null-handling that makes intent slightly ambiguous. Additionally, the reflection-based logic and duplicated null checks add complexity.
Run 3
The code has clear structure with logical method separation and descriptive names. However, readability is diminished by several issues: the 'a' and 'b' variables are meaningless (should be a single constant like JAVA_15), the overloaded newChannel methods create confusion about which version is being called, and the findOpenMethod has a catch block that silently swallows Throwable. The generic type handling with @SuppressWarnings adds complexity. The code is relatively flat with minimal nesting, and each line generally performs one action. Intent is mostly clear but the magic numbers and method overloading reduce clarity. The private constructor prevents instantiation properly. Overall it's maintainable but could be improved with better variable naming and less method overloading.
Run 1
Code Structure: Well-organized utility class with focused methods and a private constructor. Nesting: Shallow conditional and try/catch nesting keeps control flow manageable. Clarity of intent: Method names, types, and documentation generally explain the purpose, but computing Java version 15 through variables a and b unnecessarily obscures the compatibility check. Reflection, generic casts, and null-based fallback behavior require some interpretation. Code length: Compact overall, with a few redundant elements such as the version variables and temporary channel variable. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods progress naturally from method discovery to channel creation and specialized wrappers, though inconsistent parameter indentation and the somewhat awkward documentation interrupt readability.
Run 2
Code Structure: Well-organized utility class with focused methods and a private constructor. Nesting: Shallow conditionals and try/catch blocks keep complexity manageable. Clarity of intent: Descriptive method names and documentation explain channel creation, but a = 7 and b = 8 obscure the Java 15 requirement; reflection, the Object family parameter, and null fallback behavior require interpretation. Code length: Compact overall, though the version constants and temporary channel variable add minor verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Related overloads are grouped logically, and delegation is natural. However, inconsistent continuation indentation, tightly packed imports, and documentation that does not fully explain the reflective fallback slightly interrupt readability.
Run 3
Code Structure: A focused utility class with logically separated reflection lookup, channel creation, and protocol-family conversion. Nesting: Shallow conditionals and try/catch blocks keep control flow manageable. Clarity of intent: Method names and the explanatory comment communicate purpose, but variables a and b obscure the Java 15 threshold, and null returns leave fallback behavior implicit. Code length: Generally concise, though the split version constant and temporary channel variable add unnecessary lines. Action granularity: Statements mostly perform one action per line, making individual operations easy to follow. Reading flow: Lookup precedes creation helpers in a natural sequence, but overloaded newChannel methods require attention to parameter types, and inconsistent continuation indentation slightly disrupts scanning.