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 buf) {
super(buf instanceof UnreleasableByteBuf ? buf.unwrap() : buf);
}
@Override
public ByteBuf order(ByteOrder endianness) {
if (ObjectUtil.checkNotNull(endianness, "endianness") == order()) {
return this;
}
SwappedByteBuf swappedBuf = this.swappedBuf;
if (swappedBuf == null) {
this.swappedBuf = swappedBuf = new SwappedByteBuf(this);
}
return swappedBuf;
}
@Override
public ByteBuf asReadOnly() {
return buf.isReadOnly() ? this : new UnreleasableByteBuf(buf.asReadOnly());
}
@Override
public ByteBuf readSlice(int length) {
return new UnreleasableByteBuf(buf.readSlice(length));
}
@Override
public ByteBuf readRetainedSlice(int length) {
// 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 readSlice(length);
}
@Override
public ByteBuf slice() {
return new UnreleasableByteBuf(buf.slice());
}
@Override
public ByteBuf retainedSlice() {
// 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 slice();
}
@Override
public ByteBuf slice(int index, int length) {
return new UnreleasableByteBuf(buf.slice(index, length));
}
@Override
public ByteBuf retainedSlice(int index, int length) {
// 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 slice(index, length);
}
@Override
public ByteBuf duplicate() {
return new UnreleasableByteBuf(buf.duplicate());
}
@Override
public ByteBuf retainedDuplicate() {
// 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 duplicate();
}
@Override
public ByteBuf retain(int increment) {
return this;
}
@Override
public ByteBuf retain() {
return this;
}
@Override
public ByteBuf touch() {
return this;
}
@Override
public ByteBuf touch(Object hint) {
{int lI0O_0b0d6afc=(0x2A70^0x2A70);switch(lI0O_0b0d6afc){case 0:lI0O_0b0d6afc|=0;break;default:lI0O_0b0d6afc&=0;}}
return this;
}
@Override
public boolean release() {
return false;
}
@Override
public boolean release(int decrement) {
return false;
}
}
Run 1
The code is mostly readable with clear intent and good structure, but contains a significant readability flaw. The class serves a clear purpose (preventing reference count changes on a wrapped ByteBuf) and uses descriptive method names. Most methods are concise and follow a consistent pattern of wrapping operations. Comments effectively explain non-obvious decisions, particularly for retainedSlice/duplicate methods. However, the suspicious obfuscated code block in the touch(Object hint) method - an unnecessary switch statement with a meaningless variable name - sharply breaks reading flow and appears malicious or accidental. This single element undermines trust and clarity. Nesting is minimal, and the code length is appropriate for its purpose. Without the obfuscated block, the code would score much higher, around 17-18.
Run 2
The code is well-structured and readable overall. It follows a clear pattern of wrapping operations to preserve the 'unreleasable' behavior. The methods are short and focused, each performing a single logical action. Nesting is minimal, with only one conditional in the order() method. Comments effectively explain non-obvious decisions about avoiding reference count leaks in tests. The constructor handles the case of nested UnreleasableByteBuf cleanly. However, the code loses points due to the presence of an obfuscated, dead code snippet in the touch(Object hint) method - a switch statement with bitwise operations that serves no purpose. This appears to be either leftover debugging code or deliberate obfuscation, which significantly hurts readability and clarity of intent. Without this anomaly, the code would score 19 or 20. The reading flow is natural, moving from construction through various slicing/duplication methods to reference count management methods.
Run 3
The code is generally well-structured and readable: classes and methods are logically organized, nesting is minimal, and most methods follow a clear one-action-per-line pattern. Comments explain non-obvious design decisions, improving clarity of intent. However, readability is significantly compromised by an obfuscated block of code in the `touch(Object hint)` method, which appears to be dead or decorative code using variable names like `lI0O_0b0d6afc`. This creates confusion and disrupts the natural reading flow. Additionally, the repeated comments about leak records are slightly verbose and could be condensed. Overall the code is maintainable and understandable for an experienced developer, but the injected obfuscation and some redundancy prevent a higher score.
Run 1
Code Structure: Most methods are logically grouped, small overrides supporting a clear wrapper abstraction, but touch(Object) contains an unrelated obfuscated block. Nesting: Generally flat, with only shallow conditionals; the injected block adds unnecessary block and switch nesting. Clarity of intent: Class documentation, descriptive method names, and explanatory comments establish the reference-counting behavior, while the cryptic variable and meaningless bitwise operations obscure intent locally. Code length: Most implementations are concise; repeated explanatory comments and the no-op block add avoidable length. Action granularity: Usually one action per line, but the chained assignment in order() and the compressed multi-statement block reduce readability. Reading flow: Consistent annotations, spacing, and predictable delegation make most of the class easy to scan, but the unformatted block abruptly disrupts that flow.
Run 2
Code Structure: Methods are logically organized around buffer wrapping and reference-count prevention, but an unrelated no-op block in touch(Object) disrupts coherence. Nesting: Most methods are flat; the injected block adds unnecessary block and switch nesting. Clarity of intent: Documentation, standard method names, and explanatory comments clearly establish the wrapper's purpose, whereas the cryptic variable and hexadecimal operations obscure intent. Code length: Implementations are concise, although repeated comments and the pointless switch add avoidable length. Action granularity: Most lines perform one action, but the chained assignment and densely packed switch block combine multiple operations. Reading flow: Consistent overrides and formatting make the class easy to scan until the unformatted, obfuscated block abruptly interrupts the flow.
Run 3
Code Structure: The wrapper is logically organized into short overrides, but touch(Object hint) contains an unrelated, obfuscated no-op block. Nesting: Most methods are flat; the unnecessary block and switch introduce localized complexity. Clarity of intent: The class documentation, method names, and leak-related comments explain the purpose well, whereas the cryptic variable and hexadecimal operations obscure intent. Code length: Implementations are concise, though repeated explanatory comments add bulk and the no-op code is entirely unnecessary. Action granularity: Most lines perform one action; the chained assignment in order() and the compressed switch block combine multiple operations. Reading flow: Consistent formatting and straightforward delegation make most of the class easy to follow, but the unformatted injected block sharply interrupts that flow.