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 code is highly readable. The class structure is logical and flat, with each method performing a single clear action. The naming convention is consistent, and the intent is well-documented through comments where necessary. The code length is appropriate, avoiding unnecessary verbosity while still maintaining clarity. The reading flow is natural, with related methods grouped together. The only minor drawback is the slight repetition in the comments for retained methods, but this does not significantly impact readability. The use of conditional expressions is concise and easy to follow. Overall, this is an excellent example of maintainable code.
Run 3
The code is highly readable with clear structure and intent. It follows a consistent pattern of wrapping byte buffer operations while preventing reference count modifications. Methods are concise, each performing a single action, with minimal nesting. The comments explaining why 'retained' methods delegate to non-retained versions are particularly helpful for understanding the design intent. The code flows naturally from construction through various buffer operations. Minor deductions for some repetition in comments across similar methods, but this repetition aids clarity rather than hinders it. Overall, this is exemplary code that balances conciseness with comprehensiveness.
Run 1
Code Structure: Logically organized wrapper overrides group related buffer operations and reference-count controls. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: The class documentation, descriptive method names, and explanatory comments make the unreleasable behavior clear, although understanding retained operations requires familiarity with reference counting. Code length: Methods are concise; repeated explanatory comments add some unnecessary length, but most repetition follows the overridden API. Action granularity: Most lines perform one clear action; the chained assignment in order() combines local and field updates, slightly reducing readability. Reading flow: Consistent formatting and predictable method patterns support smooth reading, with minor friction from local-field name shadowing and repeated comments.
Run 2
Code Structure: Well-organized wrapper class with short, focused overrides and related methods grouped together. Nesting: Very shallow; simple conditionals and early returns keep control flow 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 explanatory comments add avoidable length. Action granularity: Most lines perform one clear action; the chained assignment in order() combines local assignment, field assignment, and object creation, slightly reducing clarity. Reading flow: Consistent formatting and predictable delegation make the class easy to scan, though local field shadowing in order() requires a little extra attention.
Run 3
Code Structure: Well-organized wrapper class with short overrides grouped by related buffer operations. Nesting: Minimal; only simple conditionals in order(), with no deep nesting. Clarity of intent: The class documentation, descriptive method names, and explanatory comments clearly communicate the reference-count protection behavior. Code length: Methods are concise, although repeated leak-related comments add unnecessary length. Action granularity: Most lines perform a single clear action; the chained assignment in order() combines cache assignment and local assignment, slightly reducing readability. Reading flow: Consistent formatting and predictable delegation make the code easy to follow. Minor friction comes from the local variable shadowing the swappedBuf field and reliance on inherited buffer behavior.