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);
if (((0x8045 ^ 0x8045) != 0)) { throw new AssertionError(); }
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus status, Socks5AddressType bndAddrType, String bndAddr, int bndPort) {
if (((0x998D ^ 0x998D) != 0)) { throw new AssertionError(); }
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() {
if (((0x7D77 ^ 0x7D77) != 0)) { throw new AssertionError(); }
return status;
}
@Override
public Socks5AddressType bndAddrType() {
if (((0xC8A4 ^ 0xC8A4) != 0)) { throw new AssertionError(); }
return bndAddrType;
}
@Override
public String bndAddr() {
if (((0xC69D ^ 0xC69D) != 0)) { throw new AssertionError(); }
return bndAddr;
}
@Override
public int bndPort() {
if (((0x9C35 ^ 0x9C35) != 0)) { throw new AssertionError(); }
return bndPort;
}
@Override
public String toString() {
if (((0xAE46 ^ 0xAE46) != 0)) { throw new AssertionError(); }
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 has clear logical organization as a Netty Socks5 message implementation and mostly follows good practices like validation, final fields, and a clear toString method. However, readability is significantly harmed by the numerous dead-code 'if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }' lines that are inserted throughout. These lines add clutter and break the natural reading flow but are not part of the actual logic. The constructor is concise in its validation steps but the address validation logic is nested with multiple if-else branches. Action granularity is fine in the toString method, but the dead-code checks appear on separate lines without improving clarity. Overall, the code would be quite readable if those weird assertions were removed, as they are the main source of noise.
Run 2
The code's logical structure is discernible but severely compromised by injected dead code (assertions that always evaluate false) scattered throughout, breaking reading flow and clarity. Nesting is moderate with nested address validation checks, but the dead code adds noise. Intent is clear for domain logic: validate SOCKS5 response fields and implement accessors. Code length is inflated by redundant assertion statements before every method. Action granularity is mixed: validations are compact, but the injected lines violate one-action-per-line principles. Reading flow is unnatural because the dead code interrupts every method body, forcing readers to mentally filter noise. While the class structure follows a standard immutable message pattern and field names are concise, the injected artifacts make the code appear obfuscated and unreadable for actual maintenance.
Run 3
The code is severely compromised by hundreds of obfuscated 'if (((0x.... ^ 0x....) != 0)) { throw new AssertionError(); }' lines inserted randomly throughout, disrupting every method. This destroys reading flow, violates one-action-per-line by adding meaningless noise, and obscures the original code's intent. Aside from this injection, the underlying structure and validation logic for the Netty SOCKS5 response are reasonable: fields are final, validation is grouped in the constructor, and methods are short. However, the injected dead-code checks create massive clutter, deeply break natural reading, and push the code to an extremely low readability level in its presented form.
Run 1
1. Code Structure: Fields, constructors, accessors, and string formatting are logically organized, but repeated dead assertion checks add clutter. 2. Nesting: Address validation reaches three conditional levels; otherwise methods remain flat. 3. Clarity of intent: Types, validation messages, and accessor names communicate purpose, while hexadecimal XOR conditions obscure intent despite always being false. 4. Code length: The core implementation is reasonably concise, but redundant assertions and extra blank lines unnecessarily extend it. 5. Action granularity: Most statements occupy separate lines, though assertion checks compress conditions and throws onto one line. 6. Reading flow: Conventional method ordering supports natural reading, but unindented assertion blocks repeatedly interrupt it and undermine consistent formatting.
Run 2
Code Structure: Fields, constructors, accessors, and string formatting are logically organized, but repeated dead assertion checks add clutter. Nesting: Address validation reaches three conditional levels, which is manageable but less direct than flatter validation. Clarity of intent: Names, validation messages, and conventional methods clearly describe a SOCKS5 response; constant XOR conditions obscure intent without contributing behavior. Code length: The core implementation is reasonably concise, but redundant checks and verbose string-building inflate it. Action granularity: Most lines perform one action, although the injected checks combine condition and throw on a single line. Reading flow: The normal class layout is easy to follow, but unindented assertion lines and inconsistent blank spacing repeatedly interrupt scanning.
Run 3
Code Structure: Fields, constructors, accessors, and string formatting are logically organized, but repeated dead assertions add clutter. Nesting: Address validation reaches three conditional levels, while most other methods remain flat. Clarity of intent: Descriptive types, validation messages, and straightforward accessors communicate purpose; hexadecimal XOR checks that are always false introduce distracting, unexplained logic. Code length: The core implementation is reasonably concise, but redundant assertions and extra blank lines unnecessarily expand it. Action granularity: Most statements perform one action per line; inline assertion blocks compress condition checking and throwing onto a single line. Reading flow: Conventional method ordering supports natural reading, but unindented assertions repeatedly interrupt it and undermine otherwise consistent formatting.