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 has severe readability issues. Structure is inconsistent: some methods are compact one-liners, while others are spaced normally, creating visual clutter. Multiple methods and fields appear on the same line, violating the 'one action per line' principle and disrupting reading flow. Although the class purpose is clear from the name and comments (preventing reference count changes), the layout makes it difficult to scan quickly. The constructor's super() call is condensed onto one line with the method signature. Methods like order() mix logic and variable assignments into dense blocks. Comments explain the reasoning behind readSlice vs readRetainedSlice well, but the overall formatting undermines clarity. The logical organization is straightforward, but poor physical organization and excessive line compression drastically reduce readability.
Run 2
The code has significant readability issues despite following some standard Java conventions. The main problems are structural: multiple method declarations appear on single lines, with several overrides and their preceding annotations crammed together (e.g., `@Override public ByteBuf retainedSlice() { ... } @Override`). This violates action granularity and obstructs reading flow. The constructor also compresses logic into one line with a ternary. Some comments are duplicated, adding length without improving clarity. Nesting is minimal and intent is reasonably clear, but the formatting is inconsistent—some methods use proper spacing while others do not. The code would benefit from consistent line breaks, one method per line, and simplified comments. Overall, the intent is understandable, but the presentation makes it unnecessarily difficult to scan and maintain.
Run 3
The code has clear intent and a logical class structure, but readability is severely hurt by inconsistent formatting and cramped layout. Multiple method declarations are placed on the same line with opening braces, and several short methods are combined on single lines, violating the 'one action per line' principle. Nesting is mostly flat, which is good, but the reading flow is disorganized due to the irregular spacing and mixed line breaks. Comments explaining design decisions are helpful, but they are often embedded in awkward places, further reducing clarity. The overall structure is understandable, but the code would benefit greatly from consistent formatting, one method or action per line, and better separation of comments from code.
Run 1
Code Structure: The wrapper class logically groups related buffer operations, but inconsistent method formatting obscures boundaries. Nesting: Control flow is shallow and easy to follow. 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 comments add unnecessary length. Action granularity: Several lines combine declarations, conditionals, annotations, or method boundaries; the chained assignment also combines updates. Reading flow: Predictable delegation and simple returns support comprehension, but crowded lines, irregular brace placement, and inconsistent annotation placement repeatedly interrupt scanning.
Run 2
Code Structure: The wrapper class is logically organized around buffer operations and reference-count protection, but inconsistent method formatting obscures boundaries. Nesting: Very shallow, with simple conditionals and short methods. Clarity of intent: Descriptive names, class documentation, and explanatory comments make the purpose clear; local variable shadowing and chained assignment slightly hinder comprehension. Code length: Implementations are concise, although repeated explanatory comments add unnecessary bulk. Action granularity: Several lines combine declarations, conditionals, annotations, method boundaries, or assignments, making individual actions harder to distinguish. Reading flow: The operation sequence is reasonable, but irregular brace placement and methods sharing lines interrupt scanning. Overall, straightforward logic is undermined primarily by compressed, inconsistent formatting.
Run 3
Code Structure: Methods are logically grouped around buffer views and reference-count operations, but inconsistent formatting obscures boundaries. Nesting: Very shallow, with simple conditionals and straightforward returns. Clarity of intent: The class documentation, descriptive method names, and explanatory comments clearly communicate the wrapper's purpose. Code length: Implementations are concise, although repeated explanatory comments add unnecessary length. Action granularity: Several lines combine declarations, conditionals, annotations, method boundaries, or chained assignments, reducing scanability. Reading flow: The functionality follows a sensible sequence, but irregular brace placement and multiple methods sharing lines repeatedly interrupt natural reading.