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);
}
@Override
protected DnsQuery newQuery(int id, InetSocketAddress nameServerAddr) {
return new DefaultDnsQuery(id);
}
@Override
protected String protocol() {
return "TCP";
}
}
Run 1
The code is well-structured and clear. The class has a single responsibility with a straightforward constructor that delegates to the superclass with appropriate parameters. The method overrides are concise and focused. The code is flat with minimal nesting. The intent is evident from class and method names. The only minor issues are the inline comment 'No retry via TCP' placed within super arguments (slightly interrupts reading flow) and the constructor parameter alignment could be improved.
Run 2
The code is generally readable with clear structure and intent. The class has a single responsibility and follows a logical organization with constructor, method override, and a small utility method. Nesting is minimal - there are no conditional blocks or deep indentation. The constructor delegates to the parent class with a clear comment explaining the 'null, false' parameters (no retry via TCP). Method names are self-documenting ('newQuery', 'protocol'). However, the constructor has many parameters (10+), which reduces readability and could benefit from a builder pattern or parameter object. The line break in the super() call feels slightly awkward, splitting 'recursionDesired' from its value. Reading flow is mostly natural but interrupted by the long parameter list. Overall, the code is concise and each method performs a single action.
Run 3
The code is well-structured and readable. It features a clear class hierarchy with TcpDnsQueryContext extending DnsQueryContext. Imports are organized and purposeful. The constructor uses clean parameter alignment and delegates to the superclass with a helpful comment explaining the 'no retry via TCP' design decision (passing null and false). Method overrides are concise and single-purpose (newQuery and protocol). There is minimal nesting and each action is clearly separated. The reading flow is natural, moving from constructor to utility methods. Minor deductions: the constructor has many parameters (though this is common in Netty-style builders), and the comment could be slightly more descriptive. Overall, it demonstrates excellent readability with clear intent and appropriate granularity.
Run 1
Code Structure: A small, logically organized subclass separates construction, query creation, and protocol identification. Nesting: Methods are flat with no nested control flow. Clarity of intent: Descriptive class and method names make the TCP-specific purpose clear, and the comment explains the lack of TCP retries. However, the long constructor and positional null/false arguments require knowledge of the superclass. Code length: Concise, with minimal implementation, though unused ChannelFuture and Future imports add clutter. Action granularity: Each method performs a single clear action; the wrapped superclass call remains one coherent operation. Reading flow: The constructor followed by short overrides reads naturally, but the dense parameter list and superclass argument mapping slightly slow comprehension.
Run 2
Code Structure: The class is logically organized into a constructor and two focused overrides. Nesting: There is no nested control flow, making it easy to scan. Clarity of intent: Descriptive class and method names clearly identify TCP DNS query behavior, and the comment explains the lack of TCP retries. However, the long constructor and positional null/false arguments require knowledge of the superclass. Code length: The implementation is concise, with no unnecessary logic, though two imports are unused. Action granularity: Each statement performs a single action; wrapping the constructor call preserves readability. Reading flow: The progression from initialization to query creation and protocol identification is natural, although the lengthy parameter list and tightly grouped imports slightly hinder scanning.
Run 3
Code Structure: A focused subclass with a constructor and two clearly separated overrides provides logical organization. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive class and method names make the TCP DNS purpose clear, and the comment explains the retry policy. However, the long constructor signature and positional null/false arguments require knowledge of the superclass. Code length: The implementation is concise, though two unused imports add minor clutter. Action granularity: Each method performs one clear action, with no compound statements. Reading flow: The constructor followed by query creation and protocol identification reads naturally; grouped parameters and the lengthy superclass call slightly reduce scanability.