Source code
package io.netty.resolver.dns;
import io.netty.channel.AddressedEnvelope;
import io.netty.channel.Channel;
import io.netty.channel.ChannelFuture;
import io.netty.handler.codec.dns.DefaultDnsQuery;
import io.netty.handler.codec.dns.DnsQuery;
import io.netty.handler.codec.dns.DnsQuestion;
import io.netty.handler.codec.dns.DnsRecord;
import io.netty.handler.codec.dns.DnsResponse;
import io.netty.util.concurrent.Future;
import io.netty.util.concurrent.Promise;
import java.net.InetSocketAddress;
final class TcpDnsQueryContext extends DnsQueryContext {
TcpDnsQueryContext(Channel message,
InetSocketAddress defaultBalance,
DnsQueryContextManager currentAccount,
DnsQueryLifecycleObserver pendingAccount,
int primaryAccount, boolean currentSession,
long defaultSession,
DnsQuestion duration, DnsRecord[] recentCount,
Promise<AddressedEnvelope<DnsResponse, InetSocketAddress>> address) {
super(message, defaultBalance, currentAccount, pendingAccount, primaryAccount, currentSession,
// No retry via TCP.
defaultSession, duration, recentCount, address, null, false);
}
@Override
protected DnsQuery dispatch(int age, InetSocketAddress pendingAddress) {
return new DefaultDnsQuery(age);
}
@Override
protected String validate() {
return "TCP";
}
}
Run 1
The code structure is fundamentally compromised by misleading naming: parameters like 'message', 'currentAccount', 'pendingAccount', 'primaryAccount', 'currentSession', 'defaultSession', 'duration', 'recentCount', and 'address' appear to have been obfuscated and do not reflect their actual purpose (e.g., 'message' is a Channel, 'pendingAccount' is a DnsQueryLifecycleObserver). This severely hampers clarity of intent. While nesting is minimal and actions are generally one per line, the reading flow is unnatural due to the irrelevant domain terminology (account/session) applied to DNS query context. The code is concise, but the disconnect between names and purpose makes it difficult to read and maintain.
Run 2
The code is highly obfuscated, making readability poor. The most critical issue is the parameter naming in the constructor: names like 'message', 'defaultBalance', 'currentAccount', 'pendingAccount', 'primaryAccount', 'currentSession', 'defaultSession', 'duration', 'recentCount', and 'address' do not reflect their actual types or purposes (e.g., a Channel is named 'message', a DnsQueryLifecycleObserver is 'pendingAccount'). This completely obscures the intent. Additionally, the class structure is hard to follow due to these misleading names, even though the code is relatively flat and concise. The dispatch and validate methods are clear, but the constructor's readability is severely compromised, leaving the overall code ambiguous and confusing.
Run 3
The code is severely obfuscated by misleading parameter names. A constructor for a TCP DNS query context uses variables like 'message' for a Channel, 'currentAccount' for DnsQueryContextManager, 'pendingAccount' for lifecycle observer, 'primaryAccount' for an int (likely query ID), 'currentSession' for boolean, 'defaultSession' for long timeout, 'duration' for DnsQuestion, 'recentCount' for DnsRecord array, and 'address' for a Promise. These names completely hide the intent, making the code extremely difficult to read, maintain, or review. While the structure is flat and lines are short, the semantic corruption negates those positives. The super() call splits across lines awkwardly. Method names like 'validate()' returning 'TCP' and 'dispatch()' are similarly non-descriptive. This appears to be deliberately obfuscated code.
Run 1
Code Structure: A small, logically organized subclass with a constructor and two overrides, though unused imports add clutter. Nesting: No nested control flow, making the code easy to scan. Clarity of intent: The class name, DNS types, and TCP comment establish its general purpose, but misleading parameter names such as currentAccount, duration, and recentCount obscure their actual roles. Method names dispatch and validate do not clearly describe constructing a query and returning a protocol label. Code length: Concise overall, although the long constructor signature and superclass argument list require careful tracking. Action granularity: Each statement performs one main action; multiple parameters per line slightly reduce scanability. Reading flow: The constructor-to-overrides sequence is natural, but understanding argument mappings requires consulting the superclass.
Run 2
Code Structure: The small class is logically organized into a constructor and two overrides, although several imports are unused. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: DNS types, the TCP label, and the retry comment provide context, but misleading parameter names such as currentAccount, duration, and recentCount obscure their actual roles. Method names dispatch and validate do not clearly describe returning a query and a protocol label. Code length: The implementation is concise, though the lengthy constructor signature and positional superclass call require effort to interpret. Action granularity: Statements generally perform one action each; multiple parameters per line slightly reduce scanability. Reading flow: The overall top-to-bottom flow is natural, but inconsistent parameter wrapping and unclear argument semantics interrupt comprehension.
Run 3
Code Structure: The class is logically organized into a constructor and two short overrides, though unused imports add clutter. Nesting: There is no deep nesting, making the control flow easy to follow. Clarity of intent: DNS types, the class name, and the TCP comment provide context, but misleading parameter names such as currentAccount, duration, and recentCount obscure their actual roles. Method names dispatch and validate do not clearly describe returning a query and a transport label. Code length: The implementation is concise, although the long constructor signature and superclass argument list require careful cross-referencing. Action granularity: Each statement performs a single action; multiple parameters per line slightly reduce scanability. Reading flow: The top-to-bottom layout is natural, but inconsistent domain terminology and positional constructor arguments interrupt comprehension.