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() >= 0xf) {
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 is well-structured with clear separation of concerns: method lookup, generic channel creation, and protocol family conversion are isolated into distinct methods. Nesting is minimal—only two levels deep in the reflection invocation block. Intent is evident from method names and the explanatory comment referencing the GitHub issue. Code length is concise with no unnecessary boilerplate. Action granularity is generally one action per line, though the 'return newChannel(...)' call combines method invocation with return, which slightly reduces granularity. Reading flow is natural: the public/package-private methods lead down to the private core implementation. Minor deductions: the magic number 0xf for Java version could use a named constant, and the suppressed unchecked cast could benefit from an explanatory comment. The private constructor correctly prevents instantiation. Overall, this is highly readable code that balances brevity with clarity in a reflection-heavy context.
Run 2
The code is generally readable with clear method names, logical separation of concerns, and adequate Javadoc for the complex internal logic. Structure is well-organized with a private constructor for a utility class. Nesting is shallow — the deepest is one try-catch inside a conditional — which is acceptable. Intent is mostly clear: wrapper methods to open channels with protocol families while handling reflective invocation. Code length is concise; no unnecessary bloat. However, some elements reduce readability: the magic number `0xf` instead of `15` or a named constant, the use of `Throwable` instead of catching specific exceptions, and `newDomainSocketChannel` calling `StandardProtocolFamily.valueOf("UNIX")` each time appears redundant. The duplicated `newChannel` overloads are slightly repetitive, though understandable for type mapping. Overall, clean but could be improved with named constants and more precise exception handling.
Run 3
The code is generally well-structured and readable. It has a clear purpose: to centralize and simplify the creation of channels via SelectorProvider. The methods are concise and each performs a single logical action. The code is relatively flat, with only one level of nesting in the main if-blocks and try-catch blocks. Naming is descriptive (e.g., 'findOpenMethod', 'newChannel', 'newDomainSocketChannel'), and there is a helpful Javadoc explaining a non-obvious optimization. However, minor readability issues exist: the magic number '0xf' obscures Java version 15, and the overloading of 'newChannel' with similar signatures could be slightly confusing. Overall, the code is clean and maintainable.
Run 1
Code Structure: A well-organized utility class separates method discovery, reflective channel creation, protocol conversion, and domain-socket creation. Nesting: Shallow conditionals and try/catch blocks keep complexity low. Clarity of intent: Descriptive method names and documentation explain most behavior, but the hexadecimal Java-version threshold (0xf), nullable fallback results, and generic Object family parameter require interpretation. Code length: Compact methods avoid unnecessary repetition, though the explanatory comment is somewhat awkward. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods progress naturally from discovery to creation helpers, but inconsistent continuation indentation and tightly packed imports slightly reduce polish. Reflection and unchecked casting add cognitive overhead, although their scope is small and explicit.
Run 2
Code Structure: Well-organized utility class with small, focused methods and a private constructor. Nesting: Shallow conditional and try/catch blocks keep complexity low. Clarity of intent: Descriptive method names and a contextual comment explain the purpose, but the hexadecimal Java version threshold, reflective invocation, and null-return fallback require interpretation. Code length: Concise overall, with little unnecessary code. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: Method grouping and straightforward control flow are natural, though inconsistent parameter indentation and the loosely typed Object family parameter slightly hinder readability.
Run 3
Code Structure: A focused utility class with small methods and sensible separation of reflection, protocol conversion, and domain-socket creation. Nesting: Shallow overall, with only modest if/try nesting. Clarity of intent: Descriptive method names and documentation communicate purpose, although the hexadecimal Java-version threshold (0xf), overloaded newChannel methods, and null-return fallback require interpretation. Code length: Concise without substantial duplication; the temporary channel variable is slightly redundant but supports the suppression annotation. Action granularity: Statements generally perform one action per line. Reading flow: Methods progress naturally from lookup to channel creation and specialized wrappers. Inconsistent parameter indentation, dense import formatting, and the broad Throwable catch slightly reduce readability.