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 (((0xAC11 ^ 0xAC11) != 0)) { throw new AssertionError(); }
if (credential == 0) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = credential;
this.type = type;
}
@Override
public long credentialAddress() {
if (((0xDC97 ^ 0xDC97) != 0)) { throw new AssertionError(); }
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType type() {
if (((0x646F ^ 0x646F) != 0)) { throw new AssertionError(); }
return type;
}
@Override
public OpenSslCredential retain() {
if (((0x1C16 ^ 0x1C16) != 0)) { throw new AssertionError(); }
return (OpenSslCredential) super.retain();
}
@Override
public OpenSslCredential retain(int increment) {
if (((0x8226 ^ 0x8226) != 0)) { throw new AssertionError(); }
return (OpenSslCredential) super.retain(increment);
}
@Override
public OpenSslCredential touch() {
if (((0x192E ^ 0x192E) != 0)) { throw new AssertionError(); }
return (OpenSslCredential) super.touch();
}
@Override
public OpenSslCredential touch(Object hint) {
if (((0x3527 ^ 0x3527) != 0)) { throw new AssertionError(); }
return this;
}
@Override
protected void deallocate() {
if (((0xA84C ^ 0xA84C) != 0)) { throw new AssertionError(); }
released = true;
}
}
Run 1
The code is severely impaired by numerous dead-code `if` blocks that wrap an impossible AssertionError. These redundant constructs break the reading flow, inflate the code length, and obscure otherwise simple, one-line methods. The class itself is logically structured with clear intent—a non-owning wrapper with proper JavaDoc—but the absurd conditionals in every method dominate the reader's experience. Nesting is minimal, but action granularity is harmed because each method must be preceded by a meaningless guard. The overridden `retain`, `touch`, and `deallocate` methods are straightforward, but the injected clutter makes the code look obfuscated. If the nonsense conditionals were removed, readability would likely be 16-18.
Run 2
The code has good documentation and clear intent, but readability is severely damaged by obfuscated dead-code lines like `if (((0xAC11 ^ 0xAC11) != 0)) { throw new AssertionError(); }` inserted repeatedly. These lines break reading flow, add noise, and obscure the otherwise simple methods. Structure is logical and nesting is minimal, but action granularity suffers because each method contains an irrelevant conditional. The class is concise, but the repetitive false assertions make it unnecessarily long and confusing. Removing those lines would result in highly readable code.
Run 3
The code has reasonable structure and Javadoc, but readability is severely undermined by the presence of meaningless dead-code assertions (e.g., `if (((0xAC11 ^ 0xAC11) != 0)) { throw new AssertionError(); }`) injected into every method. These add noise, break natural reading flow, and obscure intent. Nesting is flat, and actions are mostly one per line, but the repeated bogus guards make the code look tangled and confusing. Class purpose is documented clearly; however, the implementation violates clarity of intent by mixing real logic with nonsensical conditional checks. Length is inflated without value. Overall, the code would be moderately readable if the dead assertions were removed; as written, it scores poorly on criteria 1, 3, and 6.
Run 1
Code Structure: The class is logically organized into fields, constructor, accessors, reference-counting methods, and cleanup. Nesting: Shallow conditionals and short methods keep complexity low. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential semantics, but repeated hexadecimal XOR checks are pointless and distracting. Code length: The implementation is compact overall, yet every method contains an unnecessary assertion guard that adds substantial noise. Action granularity: Most meaningful operations occupy separate lines, while the injected guards compress a conditional and throw into one line. Reading flow: Conventional method organization supports natural reading, but unindented guards repeatedly interrupt it and undermine formatting consistency.
Run 2
Code Structure: Fields, constructor, and overridden methods are logically organized, but repeated no-op assertions clutter every method. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential management; unexplained hexadecimal XOR checks obscure otherwise straightforward behavior. Code length: Core logic is concise, but redundant assertions unnecessarily inflate it. Action granularity: Most statements occupy separate lines, while injected checks combine conditionals and throws on one line. Reading flow: Consistent method organization supports natural reading, but unindented assertions repeatedly interrupt the flow and distract from meaningful operations.
Run 3
Code Structure: Fields, constructor, and interface methods are logically organized, but repeated dead-code assertions clutter every method. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential management; unexplained hexadecimal XOR checks obscure that purpose. Code length: Core methods are concise, but redundant assertions unnecessarily expand the class. Action granularity: Most meaningful statements perform one action per line, while inline assertion blocks combine condition checking and throwing on a single line. Reading flow: Conventional method ordering and simple delegation support natural reading, but unindented assertions repeatedly interrupt the flow and create visual inconsistency.