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 cre, CredentialType typ) {
if (cre == 0) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = cre;
this.type = typ;
}
@Override
public long credential() {
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType typ() {
return type;
}
@Override
public OpenSslCredential ret() {
return (OpenSslCredential) super.retain();
}
@Override
public OpenSslCredential ret(int inc) {
return (OpenSslCredential) super.retain(inc);
}
@Override
public OpenSslCredential tou() {
return (OpenSslCredential) super.touch();
}
@Override
public OpenSslCredential tou(Object hin) {
return this;
}
@Override
protected void dea() {
released = true;
}
}
Run 1
The code follows a clear class structure with logical organization and helpful Javadoc comments explaining the non-owning credential wrapper concept. Nesting is minimal and action granularity is generally good. However, readability suffers from obfuscated method and parameter names: 'cre', 'typ', 'ret', 'tou', 'dea', and 'hin' obscure intent, requiring readers to infer meaning. The misspelled 'tou' (intended 'touch') and abbreviated 'dea' (likely 'deallocate') break Java naming conventions and reduce clarity. While the class is concise, the abbreviated identifiers undermine the otherwise clean structure. The credential() method's reference-count check is clear, but method names like 'typ' should be 'type' and 'ret' should be 'retain' to match standard patterns. Overall, the code is understandable but would be significantly more readable with proper naming.
Run 2
The code is generally well-structured and readable, with clear class-level documentation, logical field grouping, and consistent formatting. Intent is obvious: a non-owning reference-counted wrapper for a native credential pointer. Nesting is minimal and code length is appropriate. However, readability is somewhat reduced by heavily abbreviated method and parameter names (e.g., 'cre', 'typ', 'ret', 'tou', 'dea', 'hin') which obscure intent and do not follow typical Java naming conventions. The credential() method includes a guard but no null/zero check on access; this is acceptable given the constructor validation. Action granularity is generally one action per line, and reading flow is natural. Improving identifier names to be fully descriptive would significantly enhance clarity.
Run 3
The code has clear structure with logical organization, good Javadoc documentation, and acceptable nesting depth. However, readability is significantly reduced by cryptic abbreviations in method names and parameters ('cre', 'typ', 'tou', 'ret', 'dea', 'hin'), which obscure intent and make the code harder to understand without external context. While the class is concise and actions are generally one per line, the abbreviated names break the natural reading flow and require mental mapping. The overall design is sound, but clarity of intent suffers due to the terse naming conventions.
Run 1
Code Structure: Fields, constructor, accessors, and lifecycle methods are logically organized. Nesting: Minimal nesting, with only simple validation and release checks. Clarity of intent: Class documentation clearly explains non-owning semantics, but abbreviated names such as cre, typ, ret, tou, hin, and dea obscure method purposes. Constructor documentation also uses parameter names that differ from the signature. Code length: Compact and appropriately scoped, without unnecessary logic. Action granularity: Each statement performs one clear action, and methods have narrow responsibilities. Reading flow: Consistent formatting and straightforward control flow make the code easy to scan, although cryptic naming interrupts comprehension, particularly around reference-counting operations.
Run 2
Code Structure: Fields, constructor, accessors, and lifecycle methods are logically organized. Nesting: Minimal nesting, with only simple validation guards. Clarity of intent: Class documentation clearly explains non-owning behavior, but abbreviated names such as typ, ret, tou, dea, cre, and hin obscure method purposes. Constructor documentation also uses parameter names that differ from the signature. Code length: Compact, with little unnecessary code; short forwarding methods are easy to scan. Action granularity: Each statement performs one action, and assignments and checks occupy separate lines. Reading flow: Generally natural and consistent, though cryptic lifecycle method names interrupt comprehension and require readers to infer their intended relationship to reference counting.
Run 3
Code Structure: Fields, constructor, accessor methods, and lifecycle overrides are logically organized. Nesting: Minimal nesting, limited to simple validation and release checks. Clarity of intent: Class documentation clearly explains non-owning semantics, but abbreviated names such as cre, typ, ret, tou, hin, and dea obscure meaning. Constructor documentation also names parameters differently from the signature. Code length: Compact, with short methods and no unnecessary implementation complexity. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: Conventional ordering and consistent formatting support smooth reading, although cryptic lifecycle method names require readers to infer their relationship to retain, touch, and deallocation.