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;
}
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 follows a logical organization with clear separation of concerns: finding a method, creating channels, and delegating domain socket creation. Nesting is minimal, with only a couple of conditional blocks and a try-catch in the private newChannel method. Intent is clear from descriptive method names and comments. Code length is appropriate — no unnecessary repetition or excessive boilerplate. Action granularity is generally one meaningful operation per line, although the reflection invocation packs a cast and return into one line, which is acceptable. Reading flow is natural, moving from method discovery to channel creation. Minor deductions: the empty lines between methods in the middle are slightly inconsistent, and the reflection-based dynamic method lookup adds inherent complexity, but the code handles it cleanly. Overall, this is a maintainable and clear utility class.
Run 2
The code has good structure with a private constructor, helper methods, and clear separation of concerns. It is relatively flat with minimal nesting. However, there are some readability issues: the two overloaded newChannel methods have similar names and could be confusing. There is also an odd blank line block in the middle. The use of reflection and generic casting (`@SuppressWarnings`) adds some complexity. The findOpenMethod's Java version check is clear but the fallback return null is implicit. Overall, the code is fairly readable but could benefit from better naming and a comment explaining why Java 15 is checked.
Run 3
The code is well-structured with clear separation of concerns and consistent naming conventions. The nested generic method pattern is handled effectively, and each method has a single responsibility. Action granularity is appropriate, with one logical action per line. The unused import (SocketChannel) and blank space block are minor cleanliness issues. Reading flow is natural, with methods organized from general to specific. The main readability challenge is the reflective method invocation pattern, which introduces some complexity, but the code mitigates this with clear variable names and concise exception handling. Slightly verbose with three channel-creation methods that could potentially be consolidated, but keeping them separate improves clarity.
Run 1
Code Structure: Small, focused utility methods provide logical organization, although the overloaded newChannel methods require some attention. Nesting: Shallow if/try blocks keep complexity low. Clarity of intent: Descriptive method names and logging explain reflective channel creation and fallback behavior; null returns and the generic Object family parameter are less explicit. Code length: Concise overall, but excessive blank lines and an unused SocketChannel import add clutter. Action granularity: Each statement generally performs one action, making operations easy to follow. Reading flow: Method discovery, channel creation, protocol conversion, and domain-socket support form a coherent progression, though inconsistent parameter indentation and whitespace interrupt the flow.
Run 2
Code Structure: A focused utility class with small methods and centralized reflective channel creation is logically organized. Nesting: Limited to an if statement containing a try/catch, so complexity remains low. Clarity of intent: Descriptive method names and explicit protocol-family conversion communicate purpose, although overloaded newChannel methods, an Object parameter, and undocumented null returns require some inference. Code length: Concise overall, but excessive blank lines add unnecessary visual space. Action granularity: Statements generally perform one action per line; no dense compound statements obscure behavior. Reading flow: Method discovery followed by channel-creation helpers provides a natural progression, though inconsistent parameter indentation and the large blank gap interrupt scanning.
Run 3
Code Structure: A focused utility class with logically separated method discovery, reflective channel creation, and protocol-family conversion. Nesting: Shallow conditional and try/catch blocks are easy to follow. Clarity of intent: Descriptive names communicate purpose, although reflection, the Object family parameter, and null-return fallback behavior require some inference. Code length: Methods are concise, but excessive blank lines and an unused SocketChannel import add clutter. Action granularity: Statements generally perform one action per line, keeping operations distinct. Reading flow: The progression from discovery to channel creation and specialized helpers is natural; inconsistent parameter indentation and unexplained whitespace slightly disrupt it.