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 channel,
InetSocketAddress nameServerAddr,
DnsQueryContextManager queryContextManager,
DnsQueryLifecycleObserver lifecycleObserver,
int maxPayLoadSize, boolean recursionDesired,
long queryTimeoutMillis,
DnsQuestion question, DnsRecord[] additionals,
Promise<AddressedEnvelope<DnsResponse, InetSocketAddress>> promise) {
super(channel, nameServerAddr, queryContextManager, lifecycleObserver, maxPayLoadSize, recursionDesired,
// No retry via TCP.
queryTimeoutMillis, question, additionals, promise, null, false);
if (((0xBDA2 ^ 0xBDA2) != 0)) { throw new AssertionError(); }
}
@Override
protected DnsQuery newQuery(int id, InetSocketAddress nameServerAddr) {
if (((0x632F ^ 0x632F) != 0)) { throw new AssertionError(); }
return new DefaultDnsQuery(id);
}
@Override
protected String protocol() {
if (((0xB73E ^ 0xB73E) != 0)) { throw new AssertionError(); }
return "TCP";
}
}
Run 1
The code is mostly readable and follows logical structure with clear class inheritance and constructor parameters. However, there are significant readability issues: the file lacks a package declaration and proper class-level documentation, the constructor parameters are lengthy and not wrapped consistently, and most importantly, there are several meaningless dead-code blocks like `if (((0xBDA2 ^ 0xBDA2) != 0)) { throw new AssertionError(); }` that clutter the code and confuse intent. These artifacts appear to be inserted noise, possibly from obfuscation or code generation, which severely harms clarity and reading flow. Nesting is flat, action granularity is generally one action per line, and method names are clear, but the presence of confusing assertions and inconsistent spacing (e.g., no blank line before constructor) reduces overall readability.
Run 2
The code is poorly readable due to obfuscated and meaningless lines like `if (((0xBDA2 ^ 0xBDA2) != 0)) { throw new AssertionError(); }` inserted in multiple places. These lines add noise and confuse the reader without serving any purpose. The constructor is long and has many parameters, making it difficult to follow. Indentation is inconsistent, especially with the inserted assertion lines breaking the natural flow. The original code intent is somewhat clear — it's a TCP DNS query context — but the clarity is severely damaged by the dead code and poor formatting. Nesting is low, which is good, but action granularity and reading flow are disrupted. The class is short, but the unnecessary additions make it feel bloated and harder to scan. Overall, while the underlying structure is simple, the obfuscation and formatting issues make it hard to read and maintain.
Run 3
The code is generally readable with clear class structure and method separation. However, it contains suspicious dead code in the form of `if (((0xBDA2 ^ 0xBDA2) != 0)) { throw new AssertionError(); }` statements that are always false and serve no purpose. These unnecessary assertions add confusion and clutter. The constructor parameters are numerous and span multiple lines with a comment mid-argument list, which slightly disrupts reading flow. Method bodies are concise with single actions, and naming follows Java conventions. The class purpose is clear from its name and superclass. Overall, the code would be more readable if the dead code were removed and constructor parameters were better organized.
Run 1
Code Structure: The class is logically organized into a constructor and two small overrides, but unused imports and irrelevant assertion checks add clutter. Nesting: Very shallow, with no complex control flow. Clarity of intent: Class and method names clearly indicate TCP DNS query behavior; however, constant XOR conditions that are always false distract from that purpose. Code length: Core functionality is concise, but redundant checks and a long constructor parameter list increase reading effort. Action granularity: Most statements are separate, but each assertion condition and throw share a single line. Reading flow: The constructor-to-overrides order is natural, yet unindented assertion lines interrupt the otherwise consistent formatting. Positional constructor arguments, especially null and false, also require superclass knowledge.
Run 2
Code Structure: The class is logically organized into a constructor and two focused overrides, but irrelevant assertions disrupt otherwise clean methods. Nesting: Very shallow, with only single-level conditionals. Clarity of intent: Class and method names clearly describe TCP DNS query behavior, while hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: The implementation is compact, but three dead assertions and unused imports add unnecessary clutter; the long constructor parameter list increases reading effort. Action granularity: Most statements occupy separate lines, but each assertion compresses a condition and throw onto one line. Reading flow: Conventional method ordering and the TCP retry comment help, but unindented assertions, inconsistent spacing, and repeated meaningless checks interrupt the natural flow.
Run 3
Code Structure: The class is logically organized into a constructor and two small overrides, but irrelevant assertion statements disrupt otherwise clean methods. Nesting: Very shallow, with only single-level conditionals. Clarity of intent: Class and method names clearly convey TCP DNS query behavior; constant XOR expressions that always evaluate to false obscure intent and add noise. Code length: Mostly concise, but dead assertions and unused imports are unnecessary. The long constructor parameter list also increases reading effort. Action granularity: Normal statements are separated, but each assertion conditional and throw are compressed onto one line. Reading flow: The constructor-to-overrides sequence is natural, and the TCP retry comment helps explain configuration. However, unindented assertions, inconsistent spacing, and cryptic hexadecimal constants interrupt the flow.