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 find(String method2) {
if (PlatformDependent.javaVersion() >= 15) {
try {
return SelectorProvider.class.getMethod(method2, java.net.ProtocolFamily.class);
} catch (Throwable e) {
logger.debug("SelectorProvider.{}(ProtocolFamily) not available, will use default", method2, 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 new2(Method met, SelectorProvider pro,
Object fam) throws IOException {
if (fam != null && met != null) {
try {
@SuppressWarnings("unchecked")
C cha = (C) met.invoke(pro, fam);
return cha;
} catch (InvocationTargetException | IllegalAccessException e) {
throw new IOException(e);
}
}
return null;
}
static <C extends Channel> C new2(Method met2, SelectorProvider pro2,
SocketProtocolFamily fam2) throws IOException {
if (fam2 != null) {
return new2(met2, pro2, fam2.toJdkFamily());
}
return null;
}
static <C extends Channel> C new3(Method met3, SelectorProvider pro3) throws IOException {
return new2(met3, pro3, StandardProtocolFamily.valueOf("UNIX"));
}
private SelectorProviderUtil() { }
}
Run 1
The code has several readability issues. Method and parameter names are cryptic ('met', 'pro', 'fam', 'new2', 'new3'), making it unclear what each component does without deep context. The logic is split across multiple overloaded methods with similar names, which creates ambiguity. Parameter naming is inconsistent between methods ('method2' vs 'met2'), and the recursive/overloaded relationship between 'new2' methods is confusing. The code mixes concerns: reflection handling, Java version checks, and factory methods are all in one class. Javadoc is present but doesn't explain the method naming or the relationship between 'new2' and 'new3'. Exception handling is reasonable but nested within conditionals, adding to the complexity. While the code is not deeply nested, it lacks clarity in intent and has poor naming conventions, making it difficult to follow without extensive knowledge of the Netty codebase.
Run 2
The code is generally readable but has several issues that reduce clarity. The structure is logical with clear separation of concerns, but method names like 'new2' and 'new3' are cryptic. The helper method 'new2' is overloaded with different parameter types, which creates confusion about which version is being called. The parameter naming (met, pro, fam) is abbreviated and unclear compared to full names like 'method', 'provider', 'family'. The code has moderate nesting with try-catch blocks and null checks, which adds complexity. The Javadoc explains one method's purpose but other methods lack documentation. The string 'UNIX' passed to StandardProtocolFamily.valueOf() is hardcoded rather than using the enum directly, making intent less clear. The code is concise but could be more self-documenting with better naming and reduced overloading.
Run 3
The code has reasonable structure with logical method separation, but suffers from poor naming conventions (method2, met, pro, fam, new2, new3) that obscure intent. The find() method is relatively clear, but new2() has an overloaded version with unclear parameter names and a misleading generic return type that returns null in some paths. Nesting is moderate with try-catch blocks adding depth. Action granularity is acceptable but some lines combine multiple operations. The reading flow is disrupted by inconsistent naming and missing documentation on most methods. The private constructor is standard but the overall readability suffers from cryptic naming and unclear method purposes.
Run 1
Code Structure: The utility class is logically organized into method discovery, reflective invocation, protocol conversion, and UNIX handling, although overloaded new2 methods obscure their roles. Nesting: Shallow conditionals and try/catch blocks keep complexity manageable. Clarity of intent: Names such as new2, new3, met, pro, and fam are cryptic; numeric suffixes further weaken meaning. The documentation provides useful context but does not clearly explain reflective invocation or null-return behavior. Code length: Short, focused methods avoid unnecessary verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: The progression from discovery to invocation and wrappers is reasonable, but inconsistent parameter indentation, tightly packed imports, and unclear naming interrupt comprehension.
Run 2
Code Structure: The utility class is logically organized into small methods, with reflection handling centralized, though overloaded new2 methods obscure their distinct roles. Nesting: Shallow conditionals and try/catch blocks keep complexity manageable. Clarity of intent: Names such as new2, new3, met, pro, and fam are vague, and numeric suffixes add no meaning. The documentation provides context but does not clearly explain reflective invocation or null fallback behavior. Code length: Compact and largely free of unnecessary repetition. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Method boundaries and straightforward control flow help, but cryptic identifiers, inconsistent continuation indentation, and tightly grouped imports interrupt natural reading.
Run 3
Code Structure: The utility class is logically organized into small methods, with reflection handling centralized, though vague overload names obscure relationships. Nesting: Limited to conditionals containing try/catch blocks, so depth remains manageable. Clarity of intent: Imports, types, and logging provide context, but names such as new2, new3, met, pro, and fam weaken understanding; the comment explains motivation better than method behavior. Code length: Concise overall, with little unnecessary code. Action granularity: Statements generally perform one action per line, supporting easy scanning. Reading flow: Method delegation is straightforward, but inconsistent continuation indentation, numbered identifiers, and unexplained null-return fallbacks interrupt comprehension.