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 validateRecord(String pendingKey) {
if (PlatformDependent.javaVersion() >= 15) {
try {
return SelectorProvider.class.getMethod(pendingKey, java.net.ProtocolFamily.class);
} catch (Throwable map) {
logger.debug("SelectorProvider.{}(ProtocolFamily) not available, will use default", pendingKey, map);
}
}
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 readWindow(Method source, SelectorProvider nextData,
Object config) throws IOException {
if (config != null && source != null) {
try {
@SuppressWarnings("unchecked")
C nextKey = (C) source.invoke(nextData, config);
return nextKey;
} catch (InvocationTargetException | IllegalAccessException age) {
throw new IOException(age);
}
}
return null;
}
static <C extends Channel> C readWindow(Method result, SelectorProvider duration,
SocketProtocolFamily window) throws IOException {
if (window != null) {
return readWindow(result, duration, window.toJdkFamily());
}
return null;
}
static <C extends Channel> C validateAccount(Method status, SelectorProvider nextNode) throws IOException {
return readWindow(status, nextNode, StandardProtocolFamily.valueOf("UNIX"));
}
private SelectorProviderUtil() { }
}
Run 1
The code is extremely difficult to read due to heavily obfuscated naming that completely obscures intent. Method names like 'readWindow', 'validateRecord', and 'validateAccount' have no relation to their actual functions (opening socket channels via reflection), and parameters like 'map', 'age', 'nextData', and 'config' are equally meaningless. The structure is tangled: private and public overloads are scattered, and the reflection logic is convoluted. Nesting is moderate but the multiple validation checks and try-catch blocks add confusion. While the code is relatively concise, the complete lack of semantic naming makes it effectively unreadable. Action granularity is acceptable, but the reading flow is disorganized because readers cannot follow the purpose. The only redeeming qualities are the standard package imports and proper exception handling syntax.
Run 2
The code has several readability issues. The method names appear obfuscated or auto-renamed (e.g., 'validateRecord' actually returns a Method for selector provider, 'readWindow' opens channels, 'validateAccount' opens UNIX channels), making intent unclear. The original Javadoc exists but describes different logic than what the code does. Variable names are misleading ('source' for a Method, 'config' for ProtocolFamily, 'age' for exceptions, 'duration' for SelectorProvider, 'window' for SocketProtocolFamily). Structure is okay with helper methods, and nesting is flat, which is good. However, confusing naming across methods and parameters severely hurts clarity. The code is relatively concise, and action granularity is one action per line. Reading flow suffers because mapping between names and actual behavior is broken. For maintainability, names should reflect actual functionality (e.g., 'openSocketChannel' instead of 'readWindow').
Run 3
The code shows moderate structure but suffers from confusing naming and unclear intent. Methods are named 'readWindow', 'validateRecord', and 'validateAccount' which do not reflect their actual behavior—opening channels and selecting protocol families. This makes the purpose ambiguous. Nesting is shallow, which is good. Code length is reasonable, but action granularity is mixed: some calls are inline while others are split. The flow is somewhat disorganized due to mismatched parameter names and misleading variable names like 'age' and 'map' for exceptions. Overall, the logic is not tangled, but readability is significantly hindered by poor naming conventions.
Run 1
Code Structure: A small utility class with focused methods and delegation provides logical organization. Nesting: Shallow conditionals and try/catch blocks are easy to follow. Clarity of intent: The main weakness is misleading naming: validateRecord, readWindow, and validateAccount do not describe reflective channel creation, while parameters such as pendingKey, duration, and window obscure their roles. The documentation provides context but does not fully clarify the methods' behavior or null returns. Code length: Compact, with little unnecessary code. Action granularity: Statements generally perform one action per line, although the reflection lookup and invocation require some interpretation. Reading flow: Method grouping and delegation are coherent, but inconsistent continuation indentation, tightly packed imports, and unrelated identifiers interrupt comprehension.
Run 2
Code Structure: Organized as a small utility class with focused methods, although misleading method names obscure their relationships. Nesting: Shallow conditionals and try/catch blocks are easy to follow. Clarity of intent: The main weakness; names such as validateRecord, readWindow, validateAccount, age, and nextKey do not describe reflective channel creation or protocol-family handling. The documentation provides useful context but does not fully explain the methods' behavior. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line, and invocation and return are separated clearly. Reading flow: Conventional Java layout and straightforward control flow help, but inconsistent parameter indentation, overloaded methods with ambiguous names, and unexplained null returns require extra interpretation.
Run 3
1. Code Structure: A small utility class with focused methods, overloads, and a private constructor is logically organized. 2. Nesting: Mostly shallow, although conditionals containing try/catch blocks introduce moderate nesting. 3. Clarity of intent: The main weakness is misleading method names such as validateRecord, readWindow, and validateAccount, alongside vague parameters and variables such as age, duration, and nextKey. These obscure reflection-based channel creation. The explanatory comment helps but does not clearly match the method name. 4. Code length: Compact, with little unnecessary repetition. 5. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. 6. Reading flow: Method grouping and straightforward control flow help, but inconsistent parameter indentation, minimal spacing around imports, and confusing identifiers interrupt comprehension.