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 remoteItem, CredentialType data) {
if (remoteItem == 0) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = remoteItem;
this.type = data;
}
@Override
public long validateSession() {
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType emit() {
return type;
}
@Override
public OpenSslCredential handle() {
return (OpenSslCredential) super.retain();
}
@Override
public OpenSslCredential handle(int nextOrder) {
return (OpenSslCredential) super.retain(nextOrder);
}
@Override
public OpenSslCredential track() {
return (OpenSslCredential) super.touch();
}
@Override
public OpenSslCredential track(Object step) {
return this;
}
@Override
protected void findConfig() {
released = true;
}
}
Run 1
The code is highly readable with clear structure, good documentation, and logical organization. The class has a single responsibility, and methods are concise with clear intent. Nesting is minimal—only one level in the constructor and validateSession(). Each action is on its own line, and the reading flow is natural. Minor deductions: the parameter names 'remoteItem' and 'data' in the constructor are slightly ambiguous compared to the documented 'credential' and 'type'; this creates a small disconnect between documentation and implementation. Additionally, the overridden methods like handle() and track() use casts that could benefit from a brief comment explaining why the cast is safe. These are minor issues in an otherwise well-structured and maintainable class.
Run 2
The code is well-structured with clear class-level documentation and logical organization. Nesting is minimal, with only one conditional check. Intent is clearly conveyed through descriptive method names, documentation, and a straightforward class hierarchy. Code length is appropriate for the functionality. Each method performs a single action, maintaining good action granularity. Reading flow is natural and consistent. Minor issues include the parameter names in the constructor ('remoteItem' and 'data') which don't match the documented parameters ('credential' and 'type'), and the method names like 'findConfig', 'emit', and 'validateSession' are somewhat unclear without additional context. The unused 'step' parameter in the track method is slightly confusing, but the overall readability is strong.
Run 3
The code is well-structured with clear separation between fields, constructor, and methods. It uses a flat hierarchy with minimal nesting. Javadoc comments clearly explain the class purpose and BoringSSL-specific behavior. Naming is mostly clear, though the constructor parameters 'remoteItem' and 'data' don't match their Javadoc descriptions ('credential' and 'type'), slightly hurting clarity. Methods are concise and follow one-action-per-line style. Reading flow is natural: validation, getters, reference-counting overrides, then cleanup. The only minor issues are the parameter naming inconsistency and the somewhat semantic mismatch between method names like 'validateSession', 'emit', 'handle', and 'track' and their actual return values, which could be more explicit. Overall highly readable with only small improvements possible.
Run 1
Code Structure: Fields, constructor, and small overridden methods are logically organized. Nesting: Minimal nesting, limited to straightforward guard clauses. Clarity of intent: Class documentation clearly explains non-owning lifetime management, but names such as validateSession, emit, handle, track, and findConfig obscure pointer access and reference-counting operations. Constructor parameters remoteItem and data are vague and disagree with the documented parameter names credential and type. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Consistent formatting and short methods support smooth reading, although misleading names and documentation mismatches force readers to infer behavior from implementations.
Run 2
Code Structure: Logically organized into fields, construction, accessors, reference-count operations, and cleanup. Nesting: Very shallow, with only simple guard clauses. Clarity of intent: Class documentation clearly explains non-owning semantics, but names such as validateSession, emit, handle, track, and findConfig obscure actual operations. Constructor parameters remoteItem and data are vague and do not match the documented credential and type parameters. Code length: Concise, with short methods and little unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Consistent formatting and method grouping support easy scanning, but misleading names interrupt comprehension and force readers to inspect implementations to understand pointer access, retaining, touching, and release behavior.
Run 3
Code Structure: Logically organized into fields, construction, accessors, reference-count operations, and release handling. Nesting: Minimal, with only simple guard clauses. Clarity of intent: Class documentation clearly explains non-owning pointer semantics, but names such as validateSession, emit, handle, track, and findConfig obscure their actual roles. Constructor parameters remoteItem and data are vague and inconsistent with the documented credential and type parameters. Code length: Compact, with short methods and little unnecessary code. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: Method grouping and consistent formatting support natural reading, but misleading identifiers and mismatched documentation force readers to infer behavior from implementations.