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 {
return ((C) method.invoke(provider, family));
} 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 relatively readable but has some issues. Structure is logical with clear method separation, and the private constructor prevents instantiation appropriately. Nesting is mostly flat, with only two levels of depth in exception handling. Intent is clear for utility methods, and comments help explain the purpose. However, readability suffers from: (1) the duplicated 'newChannel' method names with different parameter types that create ambiguity, (2) excessive formatting with blank lines breaking natural reading flow, (3) exception handling that catches 'Throwable' instead of specific exceptions, (4) unnecessary runtime reflection complexity, and (5) the 'newChannel' overload resolution between the two public methods is not immediately obvious. The code length is adequate but could be more concise by combining methods. Action granularity is generally appropriate with one operation per line.
Run 2
The code is generally well-structured and readable. It has a clear purpose: utility methods for creating channels via reflection, avoiding repeated SelectorProvider checks. The class is final with a private constructor, showing good encapsulation. Methods are short and focused, with one main action per line. The reading flow is natural, from public API methods down to the private helper. However, the nesting in findOpenMethod (if → try → catch) adds minor complexity. The reflection-based approach necessarily obscures intent somewhat, requiring the explanatory comment for context. The generic return type with casting is slightly awkward. Some lines are long, and the method overloading could be confusing. Overall the code is maintainable but not exceptional in clarity due to its reflective nature and null-returning error handling pattern.
Run 3
The code is generally well-structured with clear separation of concerns and a private constructor enforcing utility class usage. Method names clearly express intent, and Javadoc explains the rationale for the design. Nesting is minimal, with only a single level inside methods. However, there are some minor readability issues: the generic type casting with @SuppressWarnings is implicit (the cast appears unchecked without annotation), the reflective method call logic could be clearer, and the empty line before the return statement in newChannel is unnecessary. The private newChannel method returns null when families are missing, which forces callers to handle null returns—this pattern is slightly ambiguous. Overall, the code is maintainable but could benefit from clearer null-handling documentation or alternative patterns like Optional. Score reflects strong readability with minor room for improvement in null return semantics and generic type safety clarity.
Run 1
Code Structure: A cohesive utility class with small, logically separated methods and a private constructor. Nesting: Shallow conditional and try/catch blocks are easy to follow. Clarity of intent: Descriptive method names and documentation explain channel creation, although reflection, generic casts, and null-based fallback behavior require some interpretation. Code length: Concise, with little unnecessary code; the extra blank line and redundant parentheses are minor distractions. Action granularity: Statements generally perform one action per line, with straightforward delegation between overloads. Reading flow: Natural progression from method discovery to channel creation and specialized helpers, slightly weakened by inconsistent parameter alignment and documentation that focuses on SocketChannel despite the generic Channel return type.
Run 2
Code Structure: A cohesive utility class separates method discovery, reflective channel creation, and protocol-family conversion into focused methods. Nesting: Shallow conditional and try/catch nesting keeps control flow easy to follow. Clarity of intent: Descriptive names and documentation explain the purpose, though overloaded newChannel methods, reflection, the unchecked generic cast, and null-return fallback semantics require extra attention. Code length: Compact and largely free of unnecessary code; redundant parentheses and a stray blank line add minor noise. Action granularity: Statements generally perform one action per line, with only small, understandable compositions such as conversion followed by delegation. Reading flow: Discovery precedes creation helpers in a logical sequence, but inconsistent parameter indentation and tightly packed imports slightly weaken visual organization.
Run 3
Code Structure: Small, focused utility methods organize reflection lookup, channel creation, and protocol conversion logically. Nesting: Shallow conditional and try/catch blocks are easy to follow. Clarity of intent: Descriptive names and documentation explain the main purpose, though overloaded newChannel methods, reflection, and null-return fallback behavior require some inference. Code length: Concise overall, with little unnecessary code; the extra blank line and redundant parentheses around the cast add minor clutter. Action granularity: Each statement performs one clear action, with no compressed multi-statement lines. Reading flow: Lookup precedes creation helpers, providing a natural progression. Inconsistent parameter indentation and slightly awkward documentation interrupt an otherwise clean presentation.