Source code
package io.netty.buffer;
import io.netty.util.internal.ObjectUtil;
import java.nio.ByteOrder;
/**
* A {@link ByteBuf} implementation that wraps another buffer to prevent a user from increasing or decreasing the
* wrapped buffer's reference count.
*/
final class UnreleasableByteBuf extends WrappedByteBuf {
private SwappedByteBuf swappedBuf;
UnreleasableByteBuf(ByteBuf a) {
super(a instanceof UnreleasableByteBuf ? a.unwrap() : a);
}
@Override
public ByteBuf a(ByteOrder b) {
if (ObjectUtil.checkNotNull(b, "endianness") == a()) {
return this;
}
SwappedByteBuf c = this.swappedBuf;
if (c == null) {
this.swappedBuf = c = new SwappedByteBuf(this);
}
return c;
}
@Override
public ByteBuf b() {
return buf.isReadOnly() ? this : new UnreleasableByteBuf(buf.asReadOnly());
}
@Override
public ByteBuf c(int d) {
return new UnreleasableByteBuf(buf.readSlice(d));
}
@Override
public ByteBuf d(int e) {
// We could call buf.readSlice(..), and then call buf.release(). However this creates a leak in unit tests
// because the release method on UnreleasableByteBuf will never allow the leak record to be cleaned up.
// So we just use readSlice(..) because the end result should be logically equivalent.
return c(e);
}
@Override
public ByteBuf e() {
return new UnreleasableByteBuf(buf.slice());
}
@Override
public ByteBuf f() {
// We could call buf.retainedSlice(), and then call buf.release(). However this creates a leak in unit tests
// because the release method on UnreleasableByteBuf will never allow the leak record to be cleaned up.
// So we just use slice() because the end result should be logically equivalent.
return e();
}
@Override
public ByteBuf e(int f, int g) {
return new UnreleasableByteBuf(buf.slice(f, g));
}
@Override
public ByteBuf f(int h, int i) {
// We could call buf.retainedSlice(..), and then call buf.release(). However this creates a leak in unit tests
// because the release method on UnreleasableByteBuf will never allow the leak record to be cleaned up.
// So we just use slice(..) because the end result should be logically equivalent.
return e(h, i);
}
@Override
public ByteBuf g() {
return new UnreleasableByteBuf(buf.duplicate());
}
@Override
public ByteBuf h() {
// We could call buf.retainedDuplicate(), and then call buf.release(). However this creates a leak in unit tests
// because the release method on UnreleasableByteBuf will never allow the leak record to be cleaned up.
// So we just use duplicate() because the end result should be logically equivalent.
return g();
}
@Override
public ByteBuf i(int j) {
return this;
}
@Override
public ByteBuf i() {
return this;
}
@Override
public ByteBuf j() {
return this;
}
@Override
public ByteBuf j(Object k) {
return this;
}
@Override
public boolean k() {
return false;
}
@Override
public boolean k(int l) {
return false;
}
}
Run 1
The code is highly obfuscated with single-letter method names (a, b, c, d, e, f, g, h, i, j, k), parameters, and local variables. This destroys clarity of intent, making it impossible to understand what each method does without extensive external documentation. The structure follows a class wrapper pattern but the naming eliminates readability. Nesting is relatively flat, but the ternary in the constructor and conditional swaps add complexity. Action granularity is mostly one action per line, which is positive, but comments are repetitive and don't clarify purpose. Code length is not excessive, but conciseness comes at the cost of meaningless identifiers. The reading flow is completely unnatural—method names like 'g()' returning 'duplicate()' convey no semantic meaning. While the class likely has a legitimate purpose (preventing reference count changes), the obfuscated naming makes it unreadable for anyone unfamiliar with the original source. This appears to be deliberately de-identified code, which scores very poorly on practical readability.
Run 2
This code is extremely unreadable due to meaningless method and variable names (a(), b(), c(), d(), e(), f(), etc.) that completely obscure intent. The obfuscated naming makes it impossible to understand what each method does without extensive external documentation. While the code structure is technically flat with minimal nesting, the lack of semantic naming destroys clarity. The comments are the only readable parts, indicating some awareness of the logic, but they reference methods by their obfuscated names. The single-letter parameters (a, b, c, d, e, f, g, h, i, j, k, l) make it impossible to determine purpose from context. This appears to be deliberately obfuscated code, likely for a challenge, as real production code would never use such naming. While the structure and length are reasonable, the complete absence of meaningful identifiers makes this code practically unreadable.
Run 3
The code is extremely difficult to read due to obfuscated naming (methods a(), b(), c(), etc.; parameters b, c, d, e, f, g, h, i, j, k, l) that obscures intent. The structure relies on WrappedByteBuf but method names lack semantic meaning, making action granularity and reading flow poor. Deep nesting is limited but comments are repetitive and some methods are trivial. Overly shortened names and meaningless parameters severely harm clarity of intent for a public Netty API. The class purpose is documented, but implementations are not. Overall, the code is nearly unreadable despite simple structure.
Run 1
Code Structure: Logically organized as a wrapper with small override methods and related operations grouped together. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: The class documentation and underlying buffer calls explain the overall purpose, but single-letter method and parameter names severely obscure individual operations, especially no-op methods. Code length: Methods are concise, although repeated explanatory comments add avoidable length. Action granularity: Most lines perform one action; the chained assignment to this.swappedBuf and c combines updates and slightly increases reading effort. Reading flow: Consistent formatting and predictable delegation support scanning, but ambiguous names and calls such as return e(h, i) require readers to trace definitions.
Run 2
Code Structure: Well-organized wrapper class with small override methods and related operations grouped together. Nesting: Very shallow; simple conditionals and early returns keep control flow easy to follow. Clarity of intent: The class documentation and leak-related comments explain the overall purpose, but single-letter method and parameter names obscure individual operations and make delegation harder to interpret. Code length: Implementations are concise, although repeated explanatory comments add avoidable length. Action granularity: Most lines perform one action, but the chained assignment when initializing swappedBuf combines field assignment, local assignment, and object creation. Reading flow: Consistent formatting and straightforward delegation support scanning, while overloaded single-letter names force readers to inspect method bodies to understand behavior. Overall, the clean structure is substantially undermined by ambiguous naming.
Run 3
Code Structure: Logically organized as a buffer wrapper with small override methods, though alphabetical method names obscure their roles. Nesting: Very shallow, with straightforward conditionals and early returns. Clarity of intent: The class documentation and explanatory comments establish the purpose, but single-letter method and parameter names make individual operations difficult to identify. Code length: Implementations are concise; repeated explanatory comments add some unnecessary length. Action granularity: Most lines perform one action, but the chained assignment in the swapped-buffer initialization combines field assignment, local assignment, and construction. Reading flow: Consistent formatting and related method groupings help navigation, but overloaded, cryptic names force readers to inspect delegated calls and mentally reconstruct the API.