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 a(String a) {
if (PlatformDependent.javaVersion() >= 15) {
try {
return SelectorProvider.class.getMethod(a, java.net.ProtocolFamily.class);
} catch (Throwable b) {
logger.debug("SelectorProvider.{}(ProtocolFamily) not available, will use default", a, b);
}
}
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 b(Method c, SelectorProvider d,
Object e) throws IOException {
if (e != null && c != null) {
try {
@SuppressWarnings("unchecked")
C f = (C) c.invoke(d, e);
return f;
} catch (InvocationTargetException | IllegalAccessException e) {
throw new IOException(e);
}
}
return null;
}
static <C extends Channel> C b(Method g, SelectorProvider h,
SocketProtocolFamily i) throws IOException {
if (i != null) {
return b(g, h, i.toJdkFamily());
}
return null;
}
static <C extends Channel> C c(Method j, SelectorProvider k) throws IOException {
return b(j, k, StandardProtocolFamily.valueOf("UNIX"));
}
private SelectorProviderUtil() { }
}
Run 1
The code is severely obfuscated due to cryptic naming (a, b, c, d, e, f, g, h, i, j, k) that obscures intent. It relies on method overloading and type erasure to create tangled control flow. Nesting is moderate but the reflection logic and exception handling are confusing. The code has actions scattered, with multiple concerns per method and unclear return semantics (returning null indicates fallback). Reading flow is poor because the overloaded 'b' method and generic 'C' type hide what the code actually does. While the structure is compact and comments exist, they do not compensate for the lack of self-documenting identifiers. This style may be employed for bytecode size or obfuscation, but it drastically reduces maintainability and clarity.
Run 2
The code structure is logical but readability suffers from poor naming conventions. Methods are named 'a', 'b', and 'c' which convey no meaning about their purpose, violating clarity of intent. Parameters use single-letter names (a, b, c, d, e, f, g, h, i, j, k), making the code difficult to understand without extensive context. Even the method overload for method 'b' has inconsistent parameter names between the declaration and usage. The nested try-catch blocks add moderate complexity. Action granularity is reasonable with one action per line, but the reflection logic with generic type casting reduces readability. The class has good structure with a private constructor and static utility methods, but the obfuscated naming severely hampers understanding. The comment explaining the SocketChannel optimization helps but doesn't compensate for the cryptic method names. This appears to be obfuscated production code, possibly for bytecode size reduction, which inherently trades readability for optimization.
Run 3
The code has several readability issues. Method names (a, b, c) are cryptic and fail to convey intent, making the code difficult to understand without extensive context. There's also method overloading confusion (two b methods) that adds to the ambiguity. The structure contains nested conditionals and exception handling that interrupts flow. However, the code does show some positive aspects: single actions per line, appropriate logging, and a brief comment explaining one workaround. The code is relatively concise and doesn't have excessive nesting. The main detractor is the naming scheme which severely impacts clarity of intent. Better method names describing their actual purpose (like 'findProtocolFamilyMethod' or 'openChannelWithFamily') would dramatically improve readability. The JavaDoc only partially helps since it explains one method's workaround but doesn't clarify the naming.
Run 1
Code Structure: Small, focused utility methods provide logical organization, but overloaded methods with meaningless names obscure their relationships. Nesting: Shallow conditionals and try/catch blocks are easy to follow. Clarity of intent: Imports, types, logging, and documentation suggest the purpose, but single-letter method and variable names make reflection and protocol-family handling difficult to interpret. The catch parameter also reuses the enclosing parameter name 'e', which is invalid Java and adds confusion. Code length: Concise overall, with little unnecessary code. Action granularity: Most lines perform one action, supporting readability. Reading flow: Method delegation is reasonably natural, but inconsistent continuation indentation, compressed import formatting, ambiguous identifiers, and documentation that does not directly explain the reflection helper interrupt comprehension.
Run 2
Code Structure: A small utility class with logically separated reflection lookup, invocation, and protocol-family helpers. Nesting: Shallow conditionals and try/catch blocks keep complexity manageable. Clarity of intent: Single-letter method and parameter names severely obscure purpose; overloaded b methods require tracing types to understand delegation. The documentation helps but does not clearly describe reflective invocation or null-return behavior. Code length: Compact, with little unnecessary code. Action granularity: Most statements perform one action per line, making individual operations easy to follow. Reading flow: Delegation is reasonably organized, but inconsistent continuation indentation and cryptic identifiers interrupt comprehension. Reusing e as both a parameter and catch variable also creates a naming conflict, further reducing clarity.
Run 3
Code Structure: Small, focused utility methods provide logical organization, but opaque names and overloaded b methods obscure relationships. Nesting: Shallow if/try blocks are easy to follow. Clarity of intent: Single-letter method and parameter names substantially hinder understanding; API names, logging, and documentation provide some context, although the comment does not clearly describe the reflective invocation. Code length: Compact with little unnecessary code. Action granularity: Generally one action per line, making individual operations easy to distinguish. Reading flow: The progression from method lookup to invocation and protocol-family wrappers is reasonable, but inconsistent parameter indentation and repeated null-return paths interrupt readability. The catch variable e also conflicts with the enclosing parameter e, introducing a compilation issue and additional confusion.