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))) {} else {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = credential;
this.type = type;
}
@Override
public long credentialAddress() {
if (!((released))) {} else {
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 has a clear purpose and logical class structure, with good documentation. However, readability is significantly hurt by the constructor's if-else inversion: `if (!((credential == 0))) {} else { throw ... }` is unnecessarily convoluted. A simple `if (credential == 0) throw ...` would be far clearer. The same pattern occurs in `credentialAddress()`. While the class is short and actions are generally one per line, the unnatural conditional style disrupts reading flow and obscures intent. Nesting is minimal, and the Javadoc is helpful, but this repeated awkward boolean logic is a major readability issue.
Run 2
The code has clear intent and reasonable structure, but several readability issues significantly reduce its score. The constructor includes a bizarre negated-if pattern `if (!((credential == 0))) {} else { throw ... }` which should simply be `if (credential == 0) throw ...`. The `credentialAddress()` method repeats this same awkward pattern. The `touch(Object hint)` method ignores its hint parameter and returns `this` without calling `super.touch(hint)`, which is misleading. The Javadoc is helpful but adds length without compensating for the confusing boolean logic. While the class is concise and flat, the unnatural control flow makes the code harder to understand than necessary.
Run 3
The code has clear documentation and logical structure, but readability is hurt by several issues. The constructor and credentialAddress method use awkward inverted boolean checks with empty if-branches and else-throw patterns (e.g., 'if (!((credential == 0))) {} else { throw... }'), which obscures intent and violates clean conditional logic. Nesting is shallow, but action granularity is inconsistent—multiple actions sometimes appear on one line. The class has a clear purpose and naming is mostly good, but the volatile boolean and reference-counting logic are not immediately obvious. The touch(Object hint) method returns 'this' without calling super, which may be intentional but adds ambiguity. Overall, it is maintainable but less readable than it could be with simpler guard clauses.
Run 1
Code Structure: The class is logically organized into fields, constructor, accessors, reference-count methods, and cleanup. Nesting: Very shallow, but empty if branches followed by else blocks create unnecessary complexity. Clarity of intent: Descriptive names and documentation clearly explain non-owning pointer semantics; negated conditions and redundant parentheses obscure otherwise straightforward validation. Code length: Appropriately short, with some necessary interface boilerplate and avoidable conditional verbosity. Action granularity: Most lines perform one action, although the compact empty-branch syntax reduces scanability. Reading flow: Methods follow a natural sequence, but the unusual validation style interrupts reading. Direct checks such as if (credential == 0) and if (released) would substantially improve readability.
Run 2
Code Structure: The class is logically organized around construction, accessors, reference counting, and release handling. Nesting: Control flow is shallow, but empty if branches followed by else blocks are awkward. Clarity of intent: Descriptive names and useful documentation clearly explain non-owning pointer semantics; negated conditions with redundant parentheses obscure otherwise simple validation checks. Code length: The implementation is compact, with reasonable interface-related boilerplate, though the conditionals could be shorter. Action granularity: Statements generally perform one action per line, but inline empty branches reduce visual clarity. Reading flow: Method ordering is natural and consistent; the unusual validation syntax interrupts an otherwise straightforward reading experience.
Run 3
Code Structure: The class is logically organized, with fields, constructor, accessors, reference-counting methods, and cleanup clearly separated. Nesting: Shallow throughout, although empty if branches followed by else blocks add unnecessary complexity. Clarity of intent: Descriptive names and useful documentation clearly explain non-owning pointer semantics; negated, excessively parenthesized conditions obscure otherwise simple validation and release checks. Code length: Concise overall, with short methods and justified interface overrides. Action granularity: Most lines perform one action, but inline empty branches reduce visual clarity. Reading flow: Method ordering and consistent annotations support natural reading, while the unusual conditional style interrupts it. Replacing these constructs with direct guard clauses would substantially improve readability.