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 a, CredentialType b) {
if (a == 0) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = a;
this.type = b;
}
@Override
public long a() {
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType b() {
return type;
}
@Override
public OpenSslCredential c() {
return (OpenSslCredential) super.retain();
}
@Override
public OpenSslCredential c(int c) {
return (OpenSslCredential) super.retain(c);
}
@Override
public OpenSslCredential d() {
return (OpenSslCredential) super.touch();
}
@Override
public OpenSslCredential d(Object d) {
return this;
}
@Override
protected void e() {
released = true;
}
}
Run 1
The code has a clear class structure and intent with good Javadoc, but the use of meaningless variable and method names (a, b, c, d, e) severely harms readability. The constructor parameters and all public method names fail to convey purpose, making the code ambiguous despite the explanatory comments. Nesting is minimal and each action generally occupies one line, which is positive. The class is concise and flat, with a natural flow if variable names were descriptive. However, the disconnect between the Javadoc terms (credential, type, retain, touch, release) and the actual identifiers (a, b, c, d, e) creates unnecessary cognitive load. The code would score significantly higher with proper naming.
Run 2
The code has clear purpose and structure, but readability is severely degraded by meaningless parameter names (e.g., `a`, `b`, `c`, `d`) and method names that obscure intent. Parameters like `long a` and `CredentialType b` give no indication of their roles. Method names such as `a()`, `b()`, `c()`, `d()`, and `e()` completely hide the operations they perform — likely due to obfuscation or deobfuscation artifacts. While the class is concise and has flat nesting, the naming failures force readers to rely entirely on comments and superclass contracts. The Javadoc helps somewhat, but code itself should be self-explanatory. Action granularity and reading flow suffer because each method becomes a puzzle rather than a clear statement. The structure follows a logical pattern for a reference-counted wrapper, but obfuscated names ruin clarity.
Run 3
The code structure is generally logical (clear class hierarchy, single responsibility), and nesting is minimal. However, readability is severely harmed by opaque naming: parameters 'a', 'b', 'c', 'd', methods 'a()', 'b()', 'c()', 'e()', and field 'credential' vs. parameter 'a' obscures intent. The Javadoc describes parameters 'credential' and 'type', but the code uses 'a' and 'b'. Method names like 'c()' and 'd()' give no hint of behavior (retain/touch). Length is moderate, but action granularity is okay. Reading flow is disrupted because users must decode what each single-letter name means rather than reading self-documenting code. Renaming identifiers to match Javadoc and using meaningful method names would raise the score significantly.
Run 1
Code Structure: The class is logically organized into fields, construction, accessors, reference-count operations, and release handling. Nesting: Minimal nesting and simple guards make execution easy to follow. Clarity of intent: Class documentation and descriptive field names explain the non-owning wrapper, but cryptic method names (a–e) and parameter names obscure individual operations. Constructor documentation also names parameters that do not match the signature. Code length: Concise, with little unnecessary code; repeated overrides are straightforward. Action granularity: Each line generally performs one action, making statements easy to scan. Reading flow: Consistent formatting and method grouping support natural reading, but understanding the unnamed operations requires consulting superclass or interface definitions.
Run 2
Code Structure: Logically organized into fields, constructor, accessors, and lifecycle overrides. Nesting: Very shallow, with simple guard clauses and no complex branching. Clarity of intent: Class documentation clearly explains non-ownership and external lifetime management, but single-letter method and parameter names obscure individual operations. Constructor documentation names credential and type rather than the actual parameters a and b, further reducing clarity. Code length: Concise, with short methods and little unnecessary code. Action granularity: Each statement performs one clear action; assignments, checks, and returns are separated. Reading flow: Consistent formatting and predictable method layout support easy scanning, but readers must infer the meanings of a(), b(), c(), d(), and e() from their implementations or superclass contracts.
Run 3
Code Structure: Fields, constructor, and overrides are logically organized into a compact wrapper class. Nesting: Minimal nesting and straightforward guard clauses make control flow easy to follow. Clarity of intent: Class documentation and descriptive fields explain non-owning credential semantics, but single-letter method and parameter names obscure operations such as retain, touch, and release. Constructor documentation refers to credential and type rather than the actual parameter names a and b. Code length: Concise, with little unnecessary code; short overrides are appropriate. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: The progression from initialization to accessors and lifecycle operations is natural, but cryptic method names interrupt comprehension and require readers to infer behavior from implementations.