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);
final int a = 127;
final int b = 128;
if (bndAddr.length() > (a + b)) {
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)");
}
}
}
final int c = 1;
final int d = -1;
final int e = 32767;
final int f = 32768;
if (bndPort < (c + d) || bndPort > (e + f)) {
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() {
final int g = 64;
final int h = 64;
StringBuilder buf = new StringBuilder((g + h));
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 is generally well-structured with clear field declarations, a clean constructor chain, and simple accessor methods. However, several issues reduce readability. The constant declarations in the constructor (a=127, b=128, etc.) are cryptic and obscure the intended numeric bounds; this adds unnecessary indirection and hurts clarity of intent. The validation logic uses nested if-else blocks, making it moderately deep and harder to follow. Some magic numbers remain, despite constants, because the names do not convey meaning. The port validation check also uses fragmented arithmetic instead of clear range literals. While methods are short and focused, and the class follows a logical order, the use of meaningless variable names and nested conditionals detracts from readability. Overall, the code is understandable but would benefit from clearer constants, flatter validation logic, and more descriptive names.
Run 2
The class has a clear purpose and follows a standard Netty codec pattern with proper validation, but readability suffers significantly. The code introduces cryptic local variables like 'a', 'b', 'c', 'd', etc., which obscure constants (127 + 128, 1 + -1, 32767 + 32768) instead of using named constants or direct values. The nested validation logic for address types is moderately deep but acceptable. The toString method is verbose with repetitive append calls but follows a predictable structure. Overall organization is logical, and method names are clear. However, the pointless arithmetic constants and magic numbers severely hurt clarity, making the code harder to understand than necessary.
Run 3
The code is generally well-structured with clear class purpose, consistent formatting, and logical method organization. Validation logic is properly separated in the constructor, and getters are straightforward. However, readability is significantly hurt by obscure variable names like 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h' that replace meaningful constants (e.g., 127, 128, 0, 65535, 64). This forces readers to mentally decode simple values, reducing clarity. The domain name length check uses (a + b) instead of just 255, adding unnecessary complexity. While nesting is moderate and flow of the validation is acceptable, the intent of these numeric checks is less transparent than it could be. Action granularity is generally good, with one operation per line. The toString() method is readable despite some repetition. Overall, the code is functional and maintainable but would benefit from clearer constant naming and simpler numeric conditions.
Run 1
Code Structure: Fields, constructors, accessors, and string formatting are logically organized. Nesting: Address validation reaches three conditional levels, making it moderately harder to scan, while other methods remain flat. Clarity of intent: Types, validation helpers, and exception messages communicate purpose well, but meaningless variables a–h and arithmetic expressions obscure straightforward limits and buffer capacity. Code length: Accessors are appropriately concise; unnecessary constant declarations and repetitive append calls add avoidable length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Validation followed by field assignment provides a natural progression, and formatting is consistent, but artificial arithmetic interrupts comprehension. Overall, the class is readable despite conspicuous obfuscation of simple numeric values.
Run 2
Code Structure: Well organized into immutable fields, constructors, accessors, and a string representation. Nesting: Address validation reaches three conditional levels, but remains manageable; other methods are flat. Clarity of intent: Descriptive class and method names and explicit validation messages communicate purpose, but arbitrary variables a through h and arithmetic expressions obscure straightforward limits and buffer capacity. Code length: Mostly appropriate, though unnecessary constant declarations and verbose append sequences add bulk. Action granularity: Consistently uses one operation per line, making validation and field assignment easy to follow. Reading flow: Construction proceeds naturally from validation to assignment, followed by accessors and formatting; artificial numeric decomposition interrupts otherwise clear reading.
Run 3
Code Structure: Fields, constructors, accessors, and string formatting are logically organized with clear responsibilities. Nesting: Address validation reaches three conditional levels, but remains manageable; other methods are mostly flat. Clarity of intent: Class and method names, validation helpers, and informative exceptions communicate purpose well. However, single-letter constants and arithmetic expressions obscure straightforward limits and buffer capacity. Code length: Mostly appropriate, though artificial constants and repetitive append calls add unnecessary length. Action granularity: Statements generally perform one action per line, making validation and assignments easy to follow. Reading flow: Consistent formatting and conventional method ordering support natural reading, but arbitrary numeric decompositions interrupt comprehension and require needless mental calculation.