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 status, Socks5AddressType bndAddrType) {
this(status, bndAddrType, null, 0);
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus status, Socks5AddressType bndAddrType, String bndAddr, int bndPort) {
ObjectUtil.checkNotNull(status, "status");
ObjectUtil.checkNotNull(bndAddrType, "bndAddrType");
if (bndAddr != null) {
if (bndAddrType == Socks5AddressType.IPv4) {
if (!NetUtil.isValidIpV4Address(bndAddr)) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: a valid IPv4 address)");
}
} else if (bndAddrType == Socks5AddressType.DOMAIN) {
bndAddr = IDN.toASCII(bndAddr);
if (bndAddr.length() > 255) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: less than 256 chars)");
}
} else if (bndAddrType == Socks5AddressType.IPv6) {
if (!NetUtil.isValidIpV6Address(bndAddr)) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: a valid IPv6 address)");
}
}
}
if (bndPort < 0 || bndPort > 65535) {
throw new IllegalArgumentException("bndPort: " + bndPort + " (expected: 0~65535)");
}
this.status = status;
this.bndAddrType = bndAddrType;
this.bndAddr = bndAddr;
this.bndPort = bndPort;
}
@Override
public Socks5CommandStatus status() {
return status;
}
@Override
public Socks5AddressType bndAddrType() {
return bndAddrType;
}
@Override
public String bndAddr() {
return bndAddr;
}
@Override
public int bndPort() {
return bndPort;
}
@Override
public String toString() {
StringBuilder buf = new StringBuilder(128);
buf.append(StringUtil.simpleClassName(this));
DecoderResult decoderResult = decoderResult();
if (!decoderResult.isSuccess()) {
buf.append("(decoderResult: ");
buf.append(decoderResult);
buf.append(", status: ");
} else {
buf.append("(status: ");
}
buf.append(status());
buf.append(", bndAddrType: ");
buf.append(bndAddrType());
buf.append(", bndAddr: ");
buf.append(bndAddr());
buf.append(", bndPort: ");
buf.append(bndPort());
buf.append(')');
return buf.toString();
}
}
Run 1
The code demonstrates good structure and clarity. The class has a clear single responsibility, and method organization follows a logical pattern (constructors, then getters, then toString). Validation is handled properly at construction time rather than being scattered. The nesting level in the constructor reaches three levels deep, but this is reasonable for address validation logic and remains readable. Method names are concise and self-documenting. The toString method flows well with a clear conditional branch for including decoder results. One minor readability concern is having multiple method calls on separate lines in the toString method, which slightly increases code length, but this actually improves readability by keeping each logical step distinct. The constructor parameter validation is appropriately placed with clear error messages. Overall, the code follows good Java conventions and is very maintainable.
Run 2
The code is well-structured with clear separation of concerns: validation in the constructor, getters, and a readable toString method. Nesting is moderate, with validation logic for address types remaining at two levels, which is acceptable. Intent is clearly conveyed through field names, constructor parameters, and exception messages. Code length is appropriate for the functionality, avoiding unnecessary verbosity. Most actions are on separate lines, especially in the toString method. The reading flow is natural, with validation followed by assignment and organized toString output. Minor readability improvements could include extracting the address validation into a private method to reduce constructor nesting and length, but overall the code is concise and understandable.
Run 3
The code is well-structured and readable for a Netty handler. Package/imports are clean, the class has a focused single responsibility, and method organization follows a logical order: constructor, validation, accessors, toString. The validation logic in the constructor is the weakest part: the chain of if/else-if checks adds some nesting, but each branch handles one address type and validation is explicit. Action granularity is generally one action per line, though the constructor contains multiple validation steps. Naming is clear (status, bndAddrType, bndAddr, bndPort). The toString method is verbose by necessity but follows a predictable pattern. Code length is reasonable for the requirements. Overall, this is production-quality code with minor nesting complexity in the constructor's address validation. A small refactor extracting validation into helper methods could push it higher.
Run 1
Code Structure: Fields, constructors, accessors, and string formatting are logically organized with clear separation of responsibilities. Nesting: Address validation reaches three conditional levels, but the branches remain easy to follow. Clarity of intent: Type names, validation utilities, and descriptive exception messages make the purpose clear; abbreviated bnd names require some protocol familiarity. Code length: The class is reasonably concise, though repetitive validation branches and string-builder calls add verbosity. Action granularity: Statements generally perform one action per line, making validation and initialization easy to scan. Reading flow: The progression from input checks through field assignment to accessors and diagnostic output is natural and consistent.
Run 2
Code Structure: Logically organized into immutable fields, constructors, accessors, and string formatting; validation is grouped coherently. Nesting: Address validation reaches three conditional levels, adding modest complexity, while other methods remain flat. Clarity of intent: Type names, validation utilities, and descriptive exception messages clearly communicate purpose, though abbreviated bnd names require SOCKS context. Code length: Mostly concise; standard accessor boilerplate and repetitive StringBuilder calls add some length without obscuring behavior. Action granularity: Each statement generally performs one action, making validation and field initialization easy to follow. Reading flow: Construction proceeds naturally from null checks through address and port validation to assignment, followed by accessors and diagnostics. Minor drawbacks include mutating the address parameter during normalization and long declaration and exception lines.
Run 3
Code Structure: Fields, constructors, accessors, and string formatting are logically organized, with validation grouped before initialization. Nesting: Address validation reaches three conditional levels, but branches remain short and manageable. Clarity of intent: Type-specific checks, descriptive exception messages, and straightforward accessors make the purpose clear; abbreviated bound-address names require some SOCKS familiarity. Code length: Appropriate overall, though repetitive validation and StringBuilder calls add minor verbosity. Action granularity: Nearly every line performs a single action, making operations easy to track. Reading flow: Constructor delegation, validation, assignment, and accessors follow a natural sequence; toString builds output predictably. Minor readability limitations include nested validation, sparse explanatory documentation, and long exception lines.