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() {
{
int previousNumber = 0;
int currentNumber = 1;
for (int sequenceStep = 0; sequenceStep < 4; sequenceStep++) {
int nextNumber = previousNumber + currentNumber;
previousNumber = currentNumber;
currentNumber = nextNumber;
}
}
return this;
}
@Override
public ByteBuf touch(Object hint) {
return this;
}
@Override
public boolean release() {
return false;
}
@Override
public boolean release(int decrement) {
return false;
}
}
Run 1
The code is generally well-structured with a clear class purpose documented in the Javadoc. Methods are short and follow consistent patterns, making the intent clear. However, there is a significant irregularity: an unrelated Fibonacci calculation block appears inside the touch() method, which disrupts reading flow and clarity. Aside from this, nesting is shallow, naming is descriptive, and comments explain non-obvious design decisions regarding reference counting. The implementation would otherwise be highly readable for a Netty buffer wrapper.
Run 2
The code is generally well-structured with clear class purpose and consistent method naming, but has notable readability issues. The main problems are: (1) an unrelated Fibonacci sequence code block inexplicably inserted inside the touch() method, completely breaking logical flow; (2) some methods contain verbose comments explaining why alternative implementations weren't used, which adds length; (3) inconsistent braces - the touch() method has an extra opening brace with nested code before the return statement. Positive aspects include: flat nesting (no deep conditionals), clear wrapper pattern implementation, good use of method delegation, and generally one action per line. The order() method's lazy initialization pattern is readable. Without the extraneous code block and brace issues, this would score higher. The class achieves its intent of wrapping buffers to prevent reference count changes, but the accidental code insertion and formatting inconsistencies significantly impact readability.
Run 3
The code is generally well-structured, with a clear class purpose and mostly one action per line. However, there is a major readability issue: the `touch()` method contains a completely unrelated Fibonacci sequence calculation that should not be there. This breaks the reading flow and makes the intent ambiguous. The nesting level is low, and most methods are concise and straightforward. The comments explaining why `readRetainedSlice` and similar methods delegate to non-retained versions are helpful. The constructor logic is compact but understandable. Overall readability is good except for the erroneous block in `touch()`, which is glaringly out of place and confusing.
Run 1
Code Structure: Most methods form a logically organized buffer wrapper, but the unrelated Fibonacci-style block in touch() disrupts cohesion. Nesting: Generally shallow, with simple conditionals; touch() adds an unnecessary block and loop. Clarity of intent: The class documentation, descriptive method names, and leak-related comments explain reference-count behavior well, but the unused calculation has no apparent purpose. Code length: Methods are concise, although repeated explanatory comments and the irrelevant loop add avoidable length. Action granularity: Most lines perform one action; the chained swappedBuf assignment combines updates and slightly complicates reading. Reading flow: Consistent overrides and straightforward delegation make the class easy to scan, but abruptly inconsistent indentation in touch() interrupts the otherwise natural flow.
Run 2
Code Structure: Mostly well-organized, with short overrides grouped by related buffer operations, but touch() contains an unrelated Fibonacci-style loop. Nesting: Generally shallow; the extra block and loop in touch() introduce unnecessary nesting. Clarity of intent: Class documentation, descriptive method names, and explanatory comments clearly communicate reference-count protection, while the unused calculation obscures touch()'s purpose. Code length: Methods are concise, although repeated explanatory comments and the irrelevant loop add avoidable length. Action granularity: Most lines perform one action; the chained assignment in order() combines local assignment, field assignment, and object creation. Reading flow: Consistent override formatting and predictable delegation make the class easy to scan, but the abruptly misindented block in touch() disrupts the otherwise natural flow.
Run 3
Code Structure: Mostly well-organized, with short overrides grouped by related buffer operations, but touch() contains an unrelated sequence calculation. Nesting: Generally shallow; the unnecessary block and loop in touch() add avoidable nesting. Clarity of intent: Class documentation, descriptive method names, and comments clearly explain reference-count behavior, while the unused calculation obscures touch()'s purpose. Code length: Most methods are concise, though repeated explanatory comments and dead computation add unnecessary length. Action granularity: Usually one action per line; the chained assignment in order() combines local and field updates, slightly reducing clarity. Reading flow: Consistent override formatting and predictable delegation make the class easy to scan, but the poorly indented calculation abruptly disrupts that flow.