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 ord(ByteOrder end) {
if (ObjectUtil.checkNotNull(end, "endianness") == ord()) {
return this;
}
SwappedByteBuf swapped = this.swappedBuf;
if (swapped == null) {
this.swappedBuf = swapped = new SwappedByteBuf(this);
}
return swapped;
}
@Override
public ByteBuf as() {
return buf.isReadOnly() ? this : new UnreleasableByteBuf(buf.asReadOnly());
}
@Override
public ByteBuf read(int len) {
return new UnreleasableByteBuf(buf.readSlice(len));
}
@Override
public ByteBuf read2(int len2) {
// 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 read(len2);
}
@Override
public ByteBuf sli() {
return new UnreleasableByteBuf(buf.slice());
}
@Override
public ByteBuf retained() {
// 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 sli();
}
@Override
public ByteBuf sli(int ind, int len3) {
return new UnreleasableByteBuf(buf.slice(ind, len3));
}
@Override
public ByteBuf retained(int ind2, int len4) {
// 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 sli(ind2, len4);
}
@Override
public ByteBuf dup() {
return new UnreleasableByteBuf(buf.duplicate());
}
@Override
public ByteBuf retained2() {
// 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 dup();
}
@Override
public ByteBuf ret(int inc) {
return this;
}
@Override
public ByteBuf ret() {
return this;
}
@Override
public ByteBuf tou() {
return this;
}
@Override
public ByteBuf tou(Object hin) {
return this;
}
@Override
public boolean rel() {
return false;
}
@Override
public boolean rel(int dec) {
return false;
}
}
Run 1
The code is poorly readable due to truncated and ambiguous method names (e.g., 'ord', 'sli', 'ret', 'tou', 'rel') that obscure intent. Several parameters have confusing suffix numbers ('len2', 'len3', 'ind2', 'len4') suggesting copy-paste issues. The structure is mostly flat, but the concatenation of multiple actions in a few lines reduces clarity. Comments are repetitive and interrupt flow. The class logic is understandable only with prior knowledge of Netty's ByteBuf API, and the abbreviated names make it inaccessible to general readers. Overall, the code prioritizes brevity over clarity, violating multiple readability criteria.
Run 2
The code suffers from poor and inconsistent naming (e.g., ord, as, read2, sli, retained2, ret, tou, rel) that obscures intent, making it hard to understand without guessing or external documentation. The class-level documentation is useful, but many method bodies are trivial or rely on unexplained design decisions (e.g., leak-related comments). While nesting is minimal and structure is flat, the logical organization is weakened by unclear method names and ambiguous parameter names like 'end', 'len2', 'ind2', 'len4'. Action granularity is generally one action per line, but several methods are unnecessarily abbreviated. Overall readability is significantly reduced by the cryptic, shortened identifiers and lack of self-documenting code, despite the class being relatively concise and simple in structure.
Run 3
This code is difficult to read due to heavily obfuscated method names (e.g., ord(), as(), read(), read2(), sli(), retained(), ret(), tou(), rel()). The names do not clearly convey intent, violating the 'clarity of intent' and 'reading flow' criteria. While the code structure is somewhat logical and nesting is flat, the action granularity is mixed—some methods are concise but others include redundant comments. The class wraps another buffer but the method names obscure standard ByteBuf operations like order(), asReadOnly(), readSlice(), slice(), retainedSlice(), duplicate(), retain(), touch(), and release(). This makes it hard to understand what each method does without deep domain knowledge. Comments explain some rationale but do not compensate for the naming. Overall, the code is maintainable only by someone already familiar with Netty internals.
Run 1
Code Structure: Logically organized as a buffer wrapper, with related overrides grouped together. Nesting: Very shallow; simple conditionals and short methods are easy to follow. Clarity of intent: The class documentation explains its purpose, but abbreviated names such as ord, as, sli, ret, and tou, plus numbered variants and parameters, obscure individual operations. Code length: Methods are concise, although repeated leak-explanation comments add unnecessary length. Action granularity: Most lines perform a single action; the chained assignment in ord combines cache initialization and local assignment, slightly reducing clarity. Reading flow: Consistent formatting and repetitive delegation patterns support smooth reading, but cryptic naming forces readers to inspect underlying calls to understand behavior.
Run 2
Code Structure: The class is logically organized, grouping related buffer operations and reference-count overrides into small methods. Nesting: Control flow is shallow, with simple conditionals and no loops. Clarity of intent: The class documentation and leak-related comments explain the overall purpose, but abbreviated names such as ord, as, sli, ret, and tou, plus numbered variants and parameters, obscure individual operations. Code length: Methods are concise, although repeated explanatory comments add avoidable length. Action granularity: Most lines perform one action, but the chained assignment to this.swappedBuf and swapped combines updates and slightly complicates reading. Reading flow: Consistent formatting, overrides, and straightforward delegation make the class easy to scan; cryptic naming and repetitive comments interrupt an otherwise natural flow.
Run 3
Code Structure: The class is logically organized into buffer-view operations followed by reference-count operations, with small, focused methods. Nesting: Minimal nesting and early returns make control flow easy to follow. Clarity of intent: The class documentation and explanatory comments establish the wrapper's purpose, but abbreviated names such as ord, as, sli, ret, and tou, plus numbered variants and parameters, obscure individual operations. Code length: Implementations are concise, though repeated leak-related comments add unnecessary length. Action granularity: Most lines perform one action, but the chained assignment when creating swappedBuf combines local assignment, field assignment, and construction. Reading flow: Consistent overrides and straightforward delegation provide a natural flow, weakened by cryptic naming and repetitive comments.