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, concise, and highly readable. It follows a logical organization: imports, Javadoc, class declaration, field definitions, constructor, and method overrides. Nesting is minimal, with only one if-check in the constructor and another in credentialAddress(), keeping the code flat and easy to follow. The intent is clear—the class wraps an externally owned SSL credential without freeing it—and the naming (NonOwnedOpenSslCredential, released, deallocate) supports this. Code length is appropriate; no unnecessary verbosity. Each action is on its own line, contributing to clarity. Reading flow is natural, with methods and fields arranged intuitively. Minor deductions could come from the touch(Object) override simply returning this without calling super, which may be slightly ambiguous, and the repetitive retain/touch overrides, but these are idiomatic Netty patterns.
Run 3
The code is highly readable with clear structure, minimal nesting, and explicit intent. The class is logically organized with a concise Javadoc explaining its purpose, followed by fields and well-defined methods. Nesting is effectively flat, with only a single conditional check in the constructor. Each method performs one clear action, such as returning or validating, and the use of meaningful names (e.g., NonOwnedOpenSslCredential, credentialAddress, deallocate) enhances clarity. The code is concise without sacrificing necessary detail, and the reading flow is natural—fields, constructor, then overridden methods. Minor room for improvement might include grouping or commenting the overridden retain/touch methods, but overall readability is excellent.
Run 1
Code Structure: Fields, construction, accessors, reference-counting methods, and cleanup are logically organized. Nesting: Only simple, single-level guard clauses appear. Clarity of intent: Descriptive names and focused documentation clearly explain non-owning pointer semantics and external lifetime management; the no-op touch(Object hint) could benefit from a brief explanation. Code length: Compact and appropriate, with minor repetitive delegation required by the interface. Action granularity: Each statement performs one clear action, and assignments, checks, and returns occupy separate lines. Reading flow: Consistent formatting and method grouping make the class easy to follow, although a blank line between the package declaration and imports would improve visual separation.
Run 2
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 documentation clearly explain non-owning pointer semantics and external lifetime management; the separate released flag and no-op touch behavior could benefit from brief comments. Code length: The implementation is concise, with necessary interface overrides and useful documentation. Action granularity: Each statement performs a single action, with no compressed multi-operation lines. Reading flow: Consistent formatting and short methods make the class easy to follow, though spacing between the package declaration and imports would improve presentation.
Run 3
Code Structure: Fields, constructor, accessors, reference-counting overrides, and cleanup are logically organized. Nesting: Only simple, single-level guards appear. Clarity of intent: Descriptive names and focused documentation clearly explain non-owning pointer semantics and external lifetime management; the relationship between the pointer interface and credential casts requires some API familiarity. Code length: Compact methods and relevant documentation keep the implementation concise, with minor unavoidable override repetition. Action granularity: Each statement performs one action, and validation is separated from initialization. Reading flow: Consistent formatting and a natural progression from construction to access and lifecycle management make the code easy to follow.