Source code
package io.netty.handler.codec.socksx.v5;
import io.netty.handler.codec.DecoderResult;
import io.netty.util.NetUtil;
import io.netty.util.internal.ObjectUtil;
import io.netty.util.internal.StringUtil;
import java.net.IDN;
/**
* The default {@link Socks5CommandResponse}.
*/
public final class DefaultSocks5CommandResponse extends AbstractSocks5Message implements Socks5CommandResponse {
private final Socks5CommandStatus status;
private final Socks5AddressType bndAddrType;
private final String bndAddr;
private final int bndPort;
public DefaultSocks5CommandResponse(Socks5CommandStatus sta, Socks5AddressType bnd) {
this(sta, bnd, null, 0);
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus sta2, Socks5AddressType bnd2, String bnd3, int bnd4) {
ObjectUtil.checkNotNull(sta2, "status");
ObjectUtil.checkNotNull(bnd2, "bndAddrType");
if (bnd3 != null) {
if (bnd2 == Socks5AddressType.IPv4) {
if (!NetUtil.isValidIpV4Address(bnd3)) {
throw new IllegalArgumentException("bndAddr: " + bnd3 + " (expected: a valid IPv4 address)");
}
} else if (bnd2 == Socks5AddressType.DOMAIN) {
bnd3 = IDN.toASCII(bnd3);
if (bnd3.length() > 255) {
throw new IllegalArgumentException("bndAddr: " + bnd3 + " (expected: less than 256 chars)");
}
} else if (bnd2 == Socks5AddressType.IPv6) {
if (!NetUtil.isValidIpV6Address(bnd3)) {
throw new IllegalArgumentException("bndAddr: " + bnd3 + " (expected: a valid IPv6 address)");
}
}
}
if (bnd4 < 0 || bnd4 > 65535) {
throw new IllegalArgumentException("bndPort: " + bnd4 + " (expected: 0~65535)");
}
this.status = sta2;
this.bndAddrType = bnd2;
this.bndAddr = bnd3;
this.bndPort = bnd4;
}
@Override
public Socks5CommandStatus sta() {
return status;
}
@Override
public Socks5AddressType bnd() {
return bndAddrType;
}
@Override
public String bnd2() {
return bndAddr;
}
@Override
public int bnd3() {
return bndPort;
}
@Override
public String to() {
StringBuilder buf = new StringBuilder(128);
buf.append(StringUtil.simpleClassName(this));
DecoderResult decoder = decoderResult();
if (!decoder.isSuccess()) {
buf.append("(decoderResult: ");
buf.append(decoder);
buf.append(", status: ");
} else {
buf.append("(status: ");
}
buf.append(sta());
buf.append(", bndAddrType: ");
buf.append(bnd());
buf.append(", bndAddr: ");
buf.append(bnd2());
buf.append(", bndPort: ");
buf.append(bnd3());
buf.append(')');
return buf.toString();
}
}
Run 1
The code has a clear class structure and logical flow, but readability is hampered by poor naming (sta, bnd, sta2, bnd2, etc.), ambiguous method names (to(), sta(), bnd()), and verbose constructor validation. The nested if-else chain for address validation creates moderate nesting and mixes multiple concerns. Action granularity is inconsistent—the constructor performs validation, assignment, and string conversion in one block. The toString method is relatively flat but uses many append calls, making it long. Overall, the code works but requires domain knowledge to understand the abbreviated names, reducing clarity of intent.
Run 2
The code has a clear purpose and logical structure, with reasonable field encapsulation and constructor validation. However, readability is hurt by poor naming choices: constructor parameters and methods are named 'sta', 'bnd', 'bnd2', 'bnd3', 'sta2', 'bnd2', 'bnd3', 'bnd4', which obscures intent. The `to()` method is relatively flat and readable, but the constructor has moderate nesting with an inner if-else chain. Action granularity is acceptable, though some validation logic is clustered. Overall, the code is maintainable but not particularly expressive; meaningful names would improve clarity significantly.
Run 3
The code has clear, professional Java style and simple constructor/getter structure, but variable names like sta, bnd, bnd2, bnd3, bnd4 and sta2 obscure intent. The validation logic is nested multiple levels inside the constructor, making flow harder to follow. Method names such as bnd(), bnd2(), bnd3(), and to() are unclear and break natural reading flow. Multiple validation actions are embedded in a single block, and the toString logic has an awkward conditional append pattern. The class is concise, but naming and nesting hurt readability significantly despite clean formatting.
Run 1
Code Structure: Fields, constructors, accessors, and string formatting are logically organized. Nesting: Address validation reaches three conditional levels, adding moderate complexity, while other methods remain flat. Clarity of intent: Descriptive fields and validation messages help, but abbreviated and numbered names such as sta2, bnd3, and bnd4 obscure parameter roles. Accessors named bnd2 and bnd3 and the formatting method named to further weaken intent. Code length: Reasonably compact overall, although repetitive validation branches and append statements add verbosity. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Validation followed by field assignment and accessors provides a natural progression, but inconsistent naming forces readers to repeatedly map variables and methods to their meanings.
Run 2
Code Structure: Fields, constructors, accessors, and formatting are logically grouped. Nesting: Address validation reaches three conditional levels, adding moderate complexity. Clarity of intent: Descriptive fields and validation messages help, but cryptic parameters (sta2, bnd2–bnd4) and methods (sta, bnd2, to) obscure meaning and require cross-referencing. Code length: Reasonably concise overall, although repetitive validation and append statements add verbosity. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: Validation followed by assignment and accessors provides a natural progression, but inconsistent naming interrupts comprehension.
Run 3
Code Structure: Fields, constructors, accessors, and formatting are logically grouped, with validation localized in the main constructor. Nesting: Address validation reaches three conditional levels, adding moderate complexity. Clarity of intent: Descriptive fields and error messages help, but cryptic parameters and methods such as sta2, bnd3, and to obscure meaning; numbered names represent different concepts across contexts. Code length: Reasonably compact overall, although repetitive validation and append calls add verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Construction proceeds naturally from validation to assignment, followed by accessors and formatting, but inconsistent naming forces readers to repeatedly consult field assignments.