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,
queryTimeoutMillis, question, additionals, promise, null, false);
}
@Override
protected DnsQuery newQuery(int id, InetSocketAddress nameServerAddr) {
return new DefaultDnsQuery(id);
}
@Override
protected String protocol() {
return "TCP";
}
}
Run 1
The code is generally readable but has some issues. The structure is logical with a clear class hierarchy, and method implementations are concise with flat nesting. The constructor has a long parameter list which reduces readability, and the super() call is split awkwardly with an empty line. The 'protocol()' method clearly returns TCP, and the newQuery method is straightforward. However, the many parameters passed to super() without inline comments makes it hard to understand each argument's purpose, especially when some arguments are hardcoded (null, false). The class has a single responsibility and the method names are descriptive. Action granularity is good with one action per line. The reading flow is natural, moving from constructor to query creation to protocol specification. Overall, it's readable but could be improved with a builder pattern or parameter object for the constructor, and better formatting of the super() call.
Run 2
The code is highly readable due to its clear structure and simplicity. The class has a single responsibility, extends DnsQueryContext, and overrides only necessary methods. Nesting is minimal, with no conditional logic or loops. Intent is obvious: TCP-specific DNS query context. The constructor is long but parameter ordering is consistent with the superclass, and formatting is clean. Action granularity is good—each method performs one task. Reading flow is natural, from constructor to query creation to protocol identification. Minor deductions: the constructor's many parameters reduce scanability, and the null/false arguments in the super call are slightly ambiguous without context. Overall, well-organized and maintainable code.
Run 3
The code is concise, well-structured, and maintains clear intent. The class is small and focused, with a single constructor that cleanly delegates to the superclass. Flat nesting and consistent formatting aid readability. Each parameter is on its own line, improving scanability. Method overrides are trivial and self-explanatory. Minor deductions for slightly awkward spacing around the blank line in the super() call, but this does not meaningfully impair comprehension.
Run 1
Code Structure: The class is logically organized into a constructor and two small overrides. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive class and method names clearly identify a TCP DNS query context, although the long superclass argument list and unexplained null/false arguments obscure some configuration intent. Code length: The implementation is concise, but unused imports and a stray blank line introduce minor clutter. Action granularity: Each statement performs a single action; wrapping the constructor call across lines remains understandable. Reading flow: The constructor followed by query creation and protocol identification provides a natural progression, with minor formatting inconsistencies and the lengthy constructor signature slightly interrupting readability.
Run 2
Code Structure: The class is logically organized into a constructor and two focused overrides. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive class and method names clearly indicate a TCP DNS query context, though the long constructor and unexplained null/false superclass arguments require knowledge of the parent class. Code length: The implementation is concise, with little unnecessary code; unused ChannelFuture and Future imports add minor clutter. Action granularity: Each method performs one clear action, and statements are separated cleanly. Reading flow: The constructor followed by query creation and protocol identification reads naturally, but inconsistent parameter wrapping and the stray blank line within the super call slightly disrupt visual flow.
Run 3
Code Structure: The class is logically organized into a constructor and two small overrides, though unused imports add clutter. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive class and method names clearly identify a TCP DNS query context; the long constructor parameter list and unexplained null/false superclass arguments slightly reduce clarity. Code length: The implementation is concise, with no unnecessary logic, but an extra blank line interrupts the superclass call. Action granularity: Each statement performs one clear action. Reading flow: The constructor followed by query creation and protocol identification reads naturally, although inconsistent parameter grouping and superclass-call formatting introduce minor friction.