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) {
throw new IllegalArgumentException("credential pointer must not be 0");
}
this.credential = credential;
this.type = type;
}
@Override
public long credentialAddress() {
{int lI0O_405fadea=0xCC1D;lI0O_405fadea=((lI0O_405fadea^0xCC1D)|0)&-1;if(((lI0O_405fadea&1)==1)){lI0O_405fadea^=lI0O_405fadea;}}
if (released) {
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 reasonably clear intent with Javadocs and simple method names, but readability is severely compromised by the obfuscated line in credentialAddress(): '{int lI0O_405fadea=0xCC1D;lI0O_405fadea=((lI0O_405fadea^0xCC1D)|0)&-1;if(((lI0O_405fadea&1)==1)){lI0O_405fadea^=lI0O_405fadea;}}' This appears to be dead or malicious code with no clear purpose, violating clarity of intent and reading flow. It adds unnecessary length and makes the method confusing. Structurally, the class is straightforward and flat, but the intention behind the dummy block is unclear, making it hard to trust the rest of the code. There is also a minor issue: the touch(Object) override does not call super.touch(hint), which may be intentional but is not explained. Overall, the cleanliness is overshadowed by the obfuscated line, and code length is inflated by this irrelevant block.
Run 2
The code has good structure and clear intent overall, but contains a severe readability issue: a mysterious obfuscated line in credentialAddress() that appears to be junk code or an artifact of obfuscation. This severely harms clarity and reading flow. The class is otherwise well-organized with clear naming, flat nesting, and concise methods. However, the obfuscated line violates the 'one action per line' and 'clear intent' criteria. Javadoc is helpful, and method delegation is clean. The released flag and reference counting are straightforward. Without the obfuscated line, the code would score around 17-18; with it, readability drops significantly because readers cannot understand what the code does or why it exists. Overall, the code is readable in structure but compromised by that one inclusion.
Run 3
The code is well-structured with clear class purpose, good documentation, and flat nesting. Method names and Javadoc make intent obvious. The suspicious obfuscated line inside credentialAddress() (`{int lI0O...}`) severely hurts readability—it appears to be dead/malicious code with no purpose, breaking clarity and natural flow. Apart from that anomaly, the class is concise, actions are granular, and the wrappers are straightforward.
Run 1
Code Structure: The class is logically organized into fields, constructor, accessors, reference-counting methods, and cleanup. Nesting: Most methods are flat, but credentialAddress contains an unnecessary nested block and conditional. Clarity of intent: Descriptive names and documentation clearly explain non-owning behavior; the cryptically named variable and meaningless bitwise operations obscure the accessor's purpose. Code length: The implementation is otherwise concise, with reasonable interface overrides, but the injected computation adds needless code. Action granularity: Most statements occupy separate lines; the injected block compresses multiple assignments and control flow onto one line. Reading flow: Consistent method organization and formatting support easy reading, except for the abrupt, unindented obfuscation block. Overall, the wrapper is readable, but that block noticeably undermines clarity and consistency.
Run 2
Code Structure: The class is logically organized into fields, construction, accessors, reference-count operations, and deallocation, but an unrelated obfuscated block disrupts credentialAddress(). Nesting: Most methods are flat; the inserted block adds unnecessary scope and conditional nesting. Clarity of intent: Documentation and descriptive names clearly explain non-owning credential management, whereas the cryptic variable and bitwise operations obscure intent. Code length: The wrapper is appropriately concise overall, but the no-op block adds needless code. Action granularity: Most statements perform one action per line; the injected block compresses several assignments and a conditional onto one line. Reading flow: Consistent method organization and annotations support natural reading, but the unindented, densely packed block sharply interrupts that flow.
Run 3
Code Structure: The class is logically organized into fields, construction, accessors, and reference-count lifecycle methods, but an unrelated obfuscated block disrupts credentialAddress(). Nesting: Most methods are flat; the injected block adds unnecessary scope and conditional nesting. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential semantics, while the cryptic variable and pointless bitwise operations obscure intent locally. Code length: The wrapper is otherwise concise, with straightforward delegation; the injected code adds needless complexity. Action granularity: Most statements perform one action per line, but the injected block compresses declaration, assignment, and conditional mutation onto one line. Reading flow: Consistent method organization and formatting make most of the class easy to follow, but the unindented, dense block abruptly breaks that flow.