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) {
return this;
}
@Override
public boolean release() {
return false;
}
@Override
public boolean release(int decrement) {
return false;
}
}
Run 1
The code is well-structured with clear purpose, demonstrating good readability. The class has a focused responsibility (preventing reference count changes) and follows logical organization with methods grouped by related functionality. Nesting is minimal, with only one conditional in the order() method. Variable naming is descriptive (swappedBuf, endianness) and the constructor cleverly unwraps nested instances. Comments explain non-obvious design decisions, particularly regarding potential memory leaks. The code length is appropriate, avoiding unnecessary verbosity while providing meaningful overrides. Action granularity is mostly one action per line. Reading flow is natural, with related methods grouped together. Minor improvements could include extracting the repeated leak-prevention comment into a class-level javadoc, but this doesn't significantly impact readability.
Run 2
The class is well-structured with a clear single responsibility: wrapping a ByteBuf to prevent reference count changes. Each method is concise and follows a consistent pattern, making the code predictable. Nesting is minimal—only the constructor and order() method have conditional logic, and it remains shallow. The intent is explicit through method names and a class name that clearly communicates its purpose. Comments are used sparingly but effectively to explain non-obvious decisions about avoiding leaks. Action granularity is appropriate, with one logical operation per line (e.g., wrapping and calling a delegate method). Reading flow is natural; methods are grouped by logical concern (creation methods first, then no-op lifecycle methods). Minor deductions: repeated comments and method patterns could be reduced with helper methods, and the class could benefit from a class-level Javadoc explaining broader design rationale.
Run 3
The code is highly readable. It uses a clear class name (`UnreleasableByteBuf`) and straightforward constructor logic that handles wrapping of already-unreleasable buffers. Methods are short, focused, and delegate to the wrapped buffer with minimal nesting. The pattern of overriding release/retain/touch methods to return `this` or `false` clearly communicates intent. The repeated comments in `readRetainedSlice`, `retainedSlice`, `retainedSlice(int,int)`, and `retainedDuplicate` explain non-obvious design decisions, improving clarity without excessive length. The `order` method’s lazy initialization of `SwappedByteBuf` is readable, with only a single level of nesting. Overall, the code follows best practices for a wrapper class: flat structure, consistent delegation, and purposeful comments without clutter.
Run 1
Code Structure: Logically organized wrapper methods keep buffer-view operations and reference-count overrides easy to locate. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: The class documentation, descriptive method names, and explanatory comments clearly communicate why reference-count changes are suppressed. Code length: Methods are concise, though repeated leak-related comments add avoidable length. Action granularity: Most lines perform a single action; the chained assignment in order() combines local assignment, field assignment, and construction, slightly reducing readability. Reading flow: Consistent formatting and predictable override patterns support natural reading, although local field-name shadowing and repeated comments introduce minor friction.
Run 2
Code Structure: Well-organized wrapper class with small, focused overrides and related operations grouped together. Nesting: Very shallow; simple conditionals and early returns keep control flow easy to follow. Clarity of intent: Class documentation, descriptive method names, and explanatory comments clearly convey the reference-count protection behavior. Code length: Methods are concise, although repeated leak-explanation comments add avoidable verbosity. Action granularity: Most lines perform one action; the chained assignment in order() and inline null validation slightly reduce clarity. Reading flow: Consistent formatting and predictable delegation make the code natural to scan, though local field shadowing in order() requires extra attention.
Run 3
Code Structure: A focused wrapper class with logically grouped overrides and consistent formatting. Nesting: Very shallow; simple conditionals and early returns keep methods easy to follow. Clarity of intent: The class documentation, descriptive method names, and explanatory comments clearly communicate reference-count protection and retained-view behavior. Code length: Methods are concise, although repeated leak-explanation comments add avoidable length. Action granularity: Most lines perform one action; the chained assignment in order() combines cache initialization and local assignment, slightly reducing clarity. Reading flow: Predictable delegation patterns and short methods support natural reading, though local-field name shadowing in order() requires extra attention.