Source code
package io.netty.handler.ssl;
import io.netty.util.AbstractReferenceCounted;
import io.netty.util.IllegalReferenceCountException;
/**
* A non-owning wrapper for an {@link OpenSslCredential} pointer.
*
* <p>This class is used when we need to expose an SSL_CREDENTIAL pointer that is managed
* by OpenSSL itself (e.g., the credential selected during the handshake). Unlike
* {@link DefaultOpenSslCredential}, this wrapper does not free the underlying credential
* when its reference count reaches zero, as the lifetime is managed externally.
*
* <p>This is a BoringSSL-specific feature.
*/
final class NonOwnedOpenSslCredential extends AbstractReferenceCounted implements OpenSslCredentialPointer {
private final long credential;
private final CredentialType type;
private volatile boolean released;
/**
* Creates a new non-owning credential wrapper.
*
* @param credential the native SSL_CREDENTIAL pointer (must not be 0)
* @param type the credential type
*/
NonOwnedOpenSslCredential(long credential, CredentialType type) {
if (credential == 0) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = credential;
this.type = type;
}
@Override
public long credentialAddress() {
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType type() {
return type;
}
@Override
public OpenSslCredential retain() {
return (OpenSslCredential) super.retain();
}
@Override
public OpenSslCredential retain(int increment) {
return (OpenSslCredential) super.retain(increment);
}
@Override
public OpenSslCredential touch() {
return (OpenSslCredential) super.touch();
}
@Override
public OpenSslCredential touch(Object hint) {
return this;
}
@Override
protected void deallocate() {
released = true;
}
}
Run 1
The code is highly readable with clear structure and intent. The class has a single, well-documented responsibility: wrapping an OpenSSL credential without ownership. Javadoc comments explain the purpose, lifecycle, and BoringSSL-specific nature. Fields are meaningfully named, and the constructor validates its preconditions. Methods are short and follow a consistent, predictable pattern. Nesting is flat—only one conditional exists (in credentialAddress), and it is simple. Action granularity is appropriate, with each line performing a single logical operation. The retain/touch overrides are boilerplate but concise and follow Netty conventions. Reading flow is natural: class declaration, fields, constructor, then overridden methods. Minor deductions: the touch(Object hint) override ignores the hint and returns this, which may seem puzzling without additional context, and the released flag is only checked in credentialAddress, not type(). Overall, the code is clear, maintainable, and easy to follow.
Run 2
The code is well-structured with clear separation of fields, constructor, and methods. Nesting is minimal, limited to simple null/zero checks. Intent is clearly documented through Javadoc and method names, making the non-owning behavior explicit. Code length is appropriate for the functionality. Each method performs a single action or returns a field, maintaining good action granularity. Reading flow is natural, progressing from declaration to construction and then behavior. Minor improvements could include stronger null validation for type and considering final for the released flag usage, but overall it's highly readable.
Run 3
The code is highly readable with clear structure and intent. It has a flat class hierarchy, minimal nesting, and well-documented purpose via Javadoc. Each method performs a single action, and the reading flow follows a logical sequence: fields, constructor, then methods. The volatile boolean flag for release state is clearly named and used consistently. The retain/touch methods delegate cleanly to the superclass with appropriate casts, avoiding unnecessary repetition. The constructor has a single, well-placed validation check. Overall, the code is concise, well-organized, and easy to follow.
Run 1
Code Structure: Fields, constructor, accessors, reference-counting methods, and cleanup are logically organized. Nesting: Only simple, single-level guard clauses are used. Clarity of intent: Descriptive names and documentation clearly explain non-ownership and externally managed native-pointer lifetime; the no-op touch(Object hint) could benefit from a brief explanation. Code length: Compact, with necessary interface overrides and little unnecessary code. Action granularity: Each statement performs one clear action on its own line. Reading flow: Consistent formatting and predictable method ordering make the class easy to follow, though a blank line between the package declaration and imports would improve visual separation.
Run 2
Code Structure: Fields, constructor, accessors, reference-counting overrides, and deallocation are logically organized. Nesting: Only shallow validation guards appear, keeping methods easy to scan. Clarity of intent: Descriptive names and documentation clearly explain the non-owning wrapper and externally managed lifetime; deallocate() marks release without freeing the pointer. Code length: Compact implementation with justified interface boilerplate, though repetitive casts add minor visual noise. Action granularity: Each statement performs a single action, with validation and assignments clearly separated. Reading flow: Consistent formatting and short methods provide a natural progression from initialization to access and lifecycle management. Minor readability limitations include casts whose compatibility depends on the interface hierarchy and lifecycle behavior that requires familiarity with AbstractReferenceCounted.
Run 3
Code Structure: Fields, constructor, accessors, reference-counting overrides, and deallocation are logically organized. Nesting: Only simple, single-level conditionals appear. Clarity of intent: Descriptive names and documentation clearly explain the non-owning wrapper and externally managed native lifetime; the inherited reference-counting behavior requires some framework familiarity. Code length: Short methods and minimal implementation keep the class concise, with justified interface boilerplate. Action granularity: Each statement performs one clear action, without compressed expressions. Reading flow: Consistent formatting and predictable method ordering make the code easy to follow. Minor spacing improvements around package and imports could improve presentation.