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 well-structured with clear class purpose and comprehensive documentation. It follows a logical organization with fields, constructor, and methods in a natural order. Nesting is minimal with only one if-statement in the constructor and credentialAddress method. Intent is clearly stated through the class Javadoc and method naming. The code is concise, with no redundant logic or unnecessary verbosity. Each line performs a single action, maintaining good action granularity. Reading flow is natural as methods are grouped logically with override implementations following a consistent pattern. The only minor deductions are for the touch(Object hint) method which returns 'this' instead of delegating to super, which could be slightly confusing without documentation, and the lack of a null check on the type parameter. Overall, this is highly readable and maintainable code.
Run 2
The code is highly readable. It follows a clear class structure with a specific purpose and well-defined methods. Nesting is minimal, with only a simple null check creating a single level. The intent is immediately clear from the class name, Javadoc, and method implementations. The length is appropriate, covering all necessary operations without being verbose. Each method performs a single logical action, and the reading flow is natural, starting with the constructor and moving through the implemented interface methods. The use of empty line separation between methods and the consistent formatting contribute to the overall clarity. The only minor deduction is due to the repeated 'return (OpenSslCredential) super.retain()' pattern, which is necessary for the fluent API but adds slight noise.
Run 3
The code is highly readable with clear structure and purpose. It follows a logical organization: imports, Javadoc, class declaration, fields, constructor, and overridden methods. The Javadoc comments effectively explain the non-owning nature and BoringSSL-specific use case. Nesting is minimal—only a single conditional check in the constructor. Each method has a single, clear responsibility, and actions are appropriately granular with one operation per line. Variable and method names are descriptive (credential, type, released, credentialAddress), making intent obvious without ambiguity. The code is concise without unnecessary verbosity, and the reading flow is natural, moving from construction to accessors to reference-counting overrides and cleanup. Minor improvements could include a brief comment explaining the volatile keyword, but overall readability is excellent.
Run 1
Code Structure: Fields, constructor, accessors, reference-counting overrides, and deallocation are logically organized. Nesting: Only simple guard clauses are used, keeping nesting minimal. Clarity of intent: Descriptive names and focused documentation clearly explain non-ownership and externally managed lifetime; the no-op touch(Object hint) is slightly less explicit. Code length: The implementation is concise, with necessary interface overrides and little unnecessary code. Action granularity: Each statement performs a single action, and validation is separated from initialization. Reading flow: Consistent formatting and straightforward 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 methods, and deallocation are logically organized. Nesting: Only simple, single-level guards appear. Clarity of intent: Descriptive names and documentation clearly explain the non-owning wrapper and externally managed pointer lifetime; the inherited reference-counting behavior requires some framework familiarity. Code length: Compact methods and relevant documentation avoid unnecessary length, with minor repetition in required overrides. Action granularity: Each statement performs one clear action. Reading flow: Consistent formatting and predictable method ordering make the class easy to follow, although spacing between the package and imports would slightly improve presentation.
Run 3
Code Structure: Fields, constructor, accessors, and lifecycle overrides are logically organized. Nesting: Only simple guard clauses appear, keeping methods flat. Clarity of intent: Descriptive names and focused documentation clearly explain non-owning behavior and externally managed lifetime; the relationship between the released flag and inherited reference counting requires slight background knowledge. Code length: Compact methods and necessary interface overrides avoid unnecessary complexity, though documentation is somewhat extensive for a small class. Action granularity: Each statement performs one clear action. Reading flow: Consistent formatting and predictable method ordering make the class easy to follow, with only minor spacing improvements possible around the package and imports.