Source code
package io.netty.buffer;
import java.nio.ByteBuffer;
/**
* Abstract base class for {@link ByteBuf} implementations that wrap another
* {@link ByteBuf}.
*
* @deprecated Do not use.
*/
@Deprecated
public abstract class AbstractDerivedByteBuf extends AbstractByteBuf {
protected AbstractDerivedByteBuf(int maxCapacity) {
super(maxCapacity);
}
@Override
final boolean isAccessible() {
return isAccessible0();
}
boolean isAccessible0() {
return unwrap().isAccessible();
}
@Override
public final int refCnt() {
return refCnt0();
}
int refCnt0() {
return unwrap().refCnt();
}
@Override
public final ByteBuf retain() {
return retain0();
}
ByteBuf retain0() {
unwrap().retain();
return this;
}
@Override
public final ByteBuf retain(int increment) {
return retain0(increment);
}
ByteBuf retain0(int increment) {
unwrap().retain(increment);
return this;
}
@Override
public final ByteBuf touch() {
return touch0();
}
ByteBuf touch0() {
unwrap().touch();
return this;
}
@Override
public final ByteBuf touch(Object hint) {
return touch0(hint);
}
ByteBuf touch0(Object hint) {
unwrap().touch(hint);
return this;
}
@Override
public final boolean release() {
return release0();
}
boolean release0() {
return unwrap().release();
}
@Override
public final boolean release(int decrement) {
return release0(decrement);
}
boolean release0(int decrement) {
return unwrap().release(decrement);
}
@Override
public boolean isReadOnly() {
return unwrap().isReadOnly();
}
@Override
public ByteBuffer internalNioBuffer(int index, int length) {
return nioBuffer(index, length);
}
@Override
public ByteBuffer nioBuffer(int index, int length) {
return unwrap().nioBuffer(index, length);
}
@Override
public boolean isContiguous() {
return unwrap().isContiguous();
}
}
Run 1
The code is highly readable. Structure is clear and logical: an abstract class with well-separated, grouped overrides. Nesting is flat, with only a minor two-level pattern in methods that delegate and return 'this'. Intent is explicit—the class wraps another ByteBuf and delegates reference counting, touch, and buffer operations, with naming like 'refCnt0' and 'isAccessible0' indicating internal hooks. Code length is concise; methods are short and avoid redundancy since public final methods delegate to protected/package-private templates. Action granularity is mostly one action per line, though some single-expression bodies avoid unnecessary blocks. Reading flow is natural, grouping related methods (accessibility, ref-counting, buffer metadata) and maintaining consistent delegation patterns. Minor improvements could include reducing redundant delegate methods or clarifying the deprecated nature, but overall it is highly readable.
Run 2
The code is well-structured with a clear class hierarchy and consistent delegation pattern to an unwrapped ByteBuf. Methods are flat, concise, and follow a predictable rhythm, enhancing readability. The use of final overrides delegating to non-final internal methods is a common pattern to enforce behavior, though it slightly obscures intent for the uninitiated. Action granularity is appropriate, with one primary action per line. Reading flow is natural due to logical grouping and minimal nesting. The deprecation is clear, but the abstract methods like unwrap() are implied, not shown, which may require context. Overall, highly readable.
Run 3
The code is highly readable. It demonstrates clear structure with logical grouping of related methods (refCnt, retain, touch, release). Nesting is completely flat, with each method implementing simple delegation to the wrapped buffer. The naming convention using '0' suffix for overridable methods clearly separates public final API methods from internal delegate methods, showing clear intent. Code length is appropriate for the functionality provided. Each method performs exactly one action (delegation) and returns immediately, maintaining good action granularity. The reading flow is natural and consistent - methods are organized by functionality and follow a predictable pattern. The class is well-documented for deprecation purposes, which is a minor positive aspect.
Run 1
Code Structure: Methods are logically grouped around reference counting, lifecycle operations, and buffer access, with consistent delegation patterns. Nesting: Entirely flat, with no nested control flow. Clarity of intent: The class documentation and descriptive public method names clearly establish its wrapper role, although the '0' helper suffixes and reasons for the final-method/helper split are unexplained. Code length: Individual methods are concise, but repeated forwarding helpers add boilerplate and indirection. Action granularity: Each statement performs one action, and mutation followed by returning this is clearly separated. Reading flow: Consistent formatting, annotations, and adjacent public/helper method pairs make the code easy to scan; understanding some behavior requires following delegation through helpers and unwrap().
Run 2
Code Structure: Methods are logically organized, with related overloads and delegation helpers adjacent. Nesting: Entirely flat, with no conditional or loop nesting. Clarity of intent: The class documentation and consistent unwrap() calls clearly establish its wrapper role, though helper names ending in 0 do not explain why the extra delegation layer exists. Code length: Individual methods are concise, but repeated forwarding methods add some boilerplate. Action granularity: Each statement performs one action, with mutations and returns on separate lines. Reading flow: Consistent formatting, annotations, and method patterns make the code easy to scan; frequent transitions between public methods and internal helpers slightly interrupt the flow.
Run 3
Code Structure: Logically organized into small delegation methods, with related overloads grouped together. Nesting: Completely flat, with no nested control flow. Clarity of intent: The class documentation and consistent unwrap() calls clearly communicate its wrapper role, although the '0' helper suffixes and distinction between final entry points and overridable helpers are not explained. Code length: Methods are concise, but the repeated entry-point/helper pairs add boilerplate and indirection. Action granularity: Each statement performs one action, and mutation followed by returning this is clearly separated. Reading flow: Consistent formatting, annotations, and method patterns make the class easy to scan; tracing helper calls adds minor friction.