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 {
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 and highly readable. It is organized logically with clear separation of concerns: one public helper method, one private overloaded method, and a small wrapper. Nesting is minimal, with only one level of try-catch inside an if-block. Intent is clear from method names and comments; the Javadoc explains the rationale for using SelectorProvider directly. Code length is appropriate, with no unnecessary repetition. Action granularity is generally good, with one operation per line, although method.invoke and assignment are combined in one line, which slightly reduces readability. Reading flow is natural, moving from version check to method resolution to invocation. Error handling is concise and consistent. Overall, the code is easy to follow, well-documented, and maintains a clean separation of logic, with only minor room for improvement in granularity of the reflective call.
Run 2
The code demonstrates good structure and readability with clear separation of public and private methods. It uses early returns effectively, avoiding deep nesting. The intent of each method is clear - finding reflection methods, creating channels, and handling protocol families. Method names are descriptive and follow standard Java conventions. The code is concise without being overly compressed. One minor issue is that the newDomainSocketChannel method uses `StandardProtocolFamily.valueOf("UNIX")` which could be a constant for better clarity. The reflection usage with generics and type casting adds slight complexity, but it's handled with appropriate warnings suppression. Overall, the flat structure, clear error handling, and logical organization make this code highly readable for systems-level Java code.
Run 3
The code is well-structured and highly readable. It has a clear single responsibility: finding and invoking SelectorProvider methods. The nesting is minimal, with only one or two levels in conditional blocks and try-catch statements. Intent is clearly expressed through descriptive method names and concise Javadoc explaining the rationale. Code length is appropriate—no unnecessary verbosity. Each line generally performs a single action, especially in the reflective invocation logic. The reading flow is natural, progressing from method lookup to invocation helpers. The use of helper methods avoids duplication and keeps the public API clean. Minor deductions for the slight indirection between newChannel overloads and the reliance on reflection (though unavoidable here), but overall this is exceptionally clear, maintainable code.
Run 1
Code Structure: A focused utility class with logically separated method discovery, channel creation, and protocol-family conversion. Nesting: Shallow overall, with only modest if/try nesting. Clarity of intent: Descriptive names and a rationale comment help, though reflection, generic casts, and null-based fallback behavior require interpretation. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line; compact delegation remains easy to follow. Reading flow: Methods progress naturally from discovery to creation and specialized wrappers. Minor distractions include inconsistent parameter indentation, missing spacing between package and imports, and an awkwardly worded comment.
Run 2
Code Structure: A focused utility class with small, logically separated methods and a private constructor. Nesting: Shallow overall, with only straightforward conditionals containing try/catch blocks. Clarity of intent: Descriptive names and a contextual comment explain channel creation, though reflection, generic casts, null-based fallbacks, and the Object family parameter require extra interpretation. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: Method discovery leads naturally into channel creation helpers and specialized wrappers. Minor drawbacks include uneven continuation indentation, tightly grouped imports, and a comment whose wording could explain the optimization more clearly.
Run 3
Code Structure: A focused utility class with small, logically separated methods and a private constructor. Nesting: Shallow overall, with only simple conditionals around try/catch blocks. Clarity of intent: Descriptive method names and a rationale comment explain channel creation, although reflective invocation, generic casts, and null-based fallback behavior require extra interpretation. Code length: Concise, with little duplication or unnecessary code. Action granularity: Statements generally perform one action per line, making operations easy to distinguish. Reading flow: Method discovery precedes channel creation helpers, providing a natural progression. Minor distractions include inconsistent continuation indentation, densely grouped imports, and an awkwardly worded comment. Overall, readable and well organized despite the inherent complexity of reflection.