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()))) {} else {
return this;
}
SwappedByteBuf swappedBuf = this.swappedBuf;
if (!((swappedBuf == null))) {} else {
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) {
return this;
}
@Override
public boolean release() {
return false;
}
@Override
public boolean release(int decrement) {
return false;
}
}
Run 1
The code has significant readability issues. The most problematic is the `order()` method, which uses inverted boolean logic with empty if-blocks and else-clauses, making the flow difficult to parse: `if (!(condition)) {} else { return this; }`. This pattern is unnecessarily convoluted. The constructor's nested ternary with unwrap adds minor complexity. While the class structure is logical and most methods are concise with clear intent, the comments explaining why retained methods delegate to non-retained versions are helpful but repetitive. The code would benefit from direct boolean checks and extracting the negative logic into positive conditions. Overall, the code is functional but the unnatural conditionals significantly reduce readability.
Run 2
The code is mostly structured and purpose is clear, but readability suffers due to inverted conditional patterns like `if (!(x)) {} else { ... }` instead of direct positive conditions, especially in the `order` method. This creates unnatural reading flow and unnecessary nesting. The class has clear intent and concise, one-action-per-line style in most methods, but some conditional logic is awkwardly phrased. Comments are helpful in explaining non-obvious behavior. Overall, the code is maintainable but could be significantly improved with cleaner conditionals.
Run 3
The code has a clear purpose and good documentation, but readability is significantly hurt by inconsistent conditional formatting. Several if statements use awkward structures like `if (!(condition)) {} else { ... }`, which are confusing and should be simplified to standard `if (condition == false)` or early returns. The `order()` method has convoluted logic and unnecessary null-check patterns. While the class structure is logical and method names are clear, the action granularity suffers from the multi-line conditional expressions. The repetitive comments about leak records are verbose and could be consolidated. The nesting is minimal (flat), which is positive, but the unusual if-else patterns create artificial cognitive overhead. The code length is reasonable and the overall intent is understandable, but the conditional syntax choices make it less readable than it should be.
Run 1
Code Structure: Methods are logically grouped around buffer views and reference-count operations. Nesting: Most methods are flat, with only shallow conditionals in order(). Clarity of intent: Class documentation, descriptive method names, and explanatory comments establish the wrapper's purpose, but negated conditions with empty branches obscure otherwise simple checks. Code length: Methods are concise; repeated leak-explanation comments add avoidable verbosity, though many overrides are necessary. Action granularity: Most lines perform one action, but chained assignment and validation embedded in a condition combine operations. Reading flow: Consistent overrides and straightforward delegation support natural reading, while excessive parentheses, empty branches, and local-field name shadowing interrupt the flow in order().
Run 2
Code Structure: Methods are logically grouped around buffer views and reference-count operations, with consistent overrides. Nesting: Mostly flat, although order() uses confusing negated conditions with empty branches and else blocks. Clarity of intent: The class documentation, descriptive method names, and leak-related comments explain the wrapper's purpose well; excessive parentheses and local-field shadowing obscure order(). Code length: Most methods are concise, but repeated explanatory comments add avoidable length. Action granularity: Generally one action per line, except the chained field/local assignment and inline validation within a condition. Reading flow: Consistent formatting and straightforward delegation make most of the class easy to scan, but the inverted control flow in order() interrupts otherwise natural reading.
Run 3
Code Structure: Logically organized around buffer wrapping, derived views, and reference-count operations, with consistent overrides. Nesting: Mostly flat, though order() uses confusing empty if branches and else blocks instead of straightforward guards. Clarity of intent: The class documentation, descriptive method names, and explanatory comments establish its purpose; negated conditions and excessive parentheses obscure order(). Code length: Methods are concise, but repeated lengthy comments add unnecessary bulk. Action granularity: Most lines perform one action; the chained assignment and embedded null check combine operations and increase reading effort. Reading flow: Consistent formatting and predictable delegation make most methods easy to scan, while local field-name shadowing and inverted branching interrupt the flow in order().