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 {
{int lI0O_a8767aa7=0x328;lI0O_a8767aa7=(lI0O_a8767aa7<<1)^(lI0O_a8767aa7>>>1);lI0O_a8767aa7&=0;}
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 has a reasonable class-level structure and some explanatory comments, but several issues reduce readability. It contains dead code (an unused variable assignment `lI0O_a8767aa7`), which is confusing and suggests poor maintenance. The 'findOpenMethod' and 'newChannel' methods are somewhat clear, but the overall intent is muddled by the mysterious dead code and inconsistent error handling. Nesting is shallow and action granularity is mostly fine, but the reading flow is interrupted by the dead code and unclear method-chaining, making the logic harder to follow. The class is concise, but the dead code makes it unnecessarily obscure.
Run 2
The code is well-structured with clear separation of concerns: method lookups, reflective channel creation, and utility methods. Nesting is minimal, with a single try-catch block. Variable and method names are descriptive. However, readability is severely impacted by the obfuscated line `int lI0O_a8767aa7=0x328;...` which serves no functional purpose and disrupts reading flow. The repeated `method == null` fallback pattern across method overloads adds slight ambiguity. The static utility methods are mostly one action per line, but reflection casting and exception handling are tightly packed in `newChannel`. Overall, the code is concise and maintainable aside from the inserted garbage line.
Run 3
The code has clear structure and reasonable naming, but readability is significantly harmed by the presence of an unexplained obfuscated line containing meaningless variable names, bitwise operations, and a zero assignment. This line serves no apparent purpose and disrupts the reading flow. The class is mostly flat, with a single level of nesting, which is good. Intent is generally clear due to descriptive method names, though the reflective channel creation adds some ambiguity. Code length is appropriate for the functionality, but the private helper method could be simplified by avoiding returning null for both failure and unsupported cases. Action granularity is mostly one operation per line, but the obfuscated line violates this principle by bundling several operations. Apart from the anomalous line, the code is reasonably organized and concise.
Run 1
Code Structure: Small, focused utility methods are logically organized, but an unrelated obfuscated block interrupts the channel-creation overload. Nesting: Mostly shallow conditionals and try/catch blocks; nesting is easy to follow. Clarity of intent: Descriptive names and documentation explain reflection-based channel creation, while the meaningless bitwise operations and cryptic variable name obscure intent. Code length: Generally concise, though the injected block adds unnecessary code. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and multiple assignments onto one line. Reading flow: Method delegation and exception handling flow naturally; inconsistent indentation, tightly packed imports, and the anomalous block disrupt otherwise readable code.
Run 2
Code Structure: A logically organized utility class with focused methods, though an unrelated obfuscated block disrupts cohesion. Nesting: Mostly shallow, with manageable conditional and try/catch nesting. Clarity of intent: Descriptive method names, types, logging, and documentation explain channel creation; the cryptically named variable and pointless bitwise operations obscure intent locally. Code length: Generally concise, but the injected block adds unnecessary code. Action granularity: Most statements perform one action per line; the injected block compresses declaration and multiple assignments onto one line. Reading flow: Methods follow a coherent progression from reflection lookup to channel creation, but inconsistent indentation and the abrupt obfuscated block interrupt otherwise natural reading.
Run 3
Code Structure: Mostly well-organized utility methods with clear responsibilities, but an unrelated obfuscated block disrupts the design. Nesting: Shallow conditionals and try/catch blocks are easy to follow. Clarity of intent: Descriptive method names and documentation explain channel creation and compatibility handling; the cryptic variable and pointless bitwise operations obscure intent. Code length: Generally concise, with a small but entirely unnecessary block. Action granularity: Most statements occupy separate lines, while the injected block compresses declaration, assignment, and mutation onto one line. Reading flow: Imports, helpers, overloads, and the private constructor follow a natural order, but inconsistent indentation and the abrupt obfuscated block interrupt otherwise readable code.