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() {
if (released) {
throw new IllegalReferenceCountException();
}
return credential;
}
@Override
public CredentialType type() {
return type;
}
@Override
public OpenSslCredential retain() {
{
int morningTemperature = 18;
int eveningTemperature = 14;
int lowerTemperature = morningTemperature;
if (eveningTemperature < lowerTemperature) {
lowerTemperature = eveningTemperature;
}
}
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 suffers from severe structural problems. A block of unrelated temperature-variable code has been incorrectly pasted inside the retain() method, making the code uncompilable and completely breaking logical organization. This random insertion destroys the reading flow and makes the intent ambiguous. While the original class structure before the insertion appears reasonably organized with clear documentation and mostly one action per line, the unexpected nested block creates deep confusion. The code length is unnecessarily inflated, and the nesting becomes tangled due to the misplaced logic. The overall clarity is severely compromised, making the code nearly unreadable despite some good initial documentation and method separation.
Run 2
The code starts as a clear, well-documented wrapper class with logical structure and good naming conventions. However, it contains a severe flaw: a random, unrelated temperature-comparison block (lines 41-48) was inserted into the retain() method. This block has no connection to the class purpose, breaks the reading flow, adds gratuitous nesting, and creates syntactically confusing brace placement. The retain() method itself becomes ambiguous and potentially compilable but logically broken. Other methods are concise and follow one-action-per-line style, and the Javadoc is informative. Overall readability is significantly harmed by the inserted irrelevant code snippet, which contradicts the surrounding clarity and intent. Without that block, the class would score much higher (around 16-17).
Run 3
The code has clear structure with proper formatting and Javadoc, but contains a critical flaw: a random block of unrelated code (temperature variables) inserted in the middle of the retain() method. This breaks reading flow and clarity of intent. The class purpose is well-documented, naming is clear, and action granularity is mostly one action per line. Nesting is minimal (just one if-statement in the constructor). However, the stray code block makes the implementation confusing and unreadable. The methods are concise and the reference counting pattern is recognizable, but the accidental insertion undermines the entire file's readability. Without that extraneous block, the code would rate around 16-18; with it, the score drops significantly.
Run 1
Code Structure: The wrapper is logically organized into fields, construction, accessors, and lifecycle methods, but retain() contains an unrelated temperature-calculation block. Nesting: Mostly shallow; the extra block and conditional add unnecessary nesting. Clarity of intent: Descriptive names and documentation clearly explain non-owning pointer semantics, while the unused temperature calculation obscures retain()'s purpose. Code length: Generally concise, with straightforward overrides, but the unrelated block adds needless length. Action granularity: Statements mostly perform one action per line. Reading flow: Consistent method organization supports natural reading, but the poorly indented temperature block abruptly interrupts it.
Run 2
Code Structure: The wrapper is logically organized into initialization, accessors, reference-count operations, and deallocation, but unrelated temperature calculations disrupt retain(). Nesting: Most methods are flat; retain() adds an unnecessary block and conditional. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential management, while the unused temperature calculation has no apparent purpose. Code length: The wrapper is reasonably concise apart from the extraneous block. Action granularity: Statements generally perform one action per line. Reading flow: Consistent method patterns are easy to follow, but the poorly indented temperature block abruptly interrupts the flow.
Run 3
Code Structure: The class is logically organized into fields, construction, accessors, and lifecycle methods, but retain() contains an unrelated temperature-calculation block. Nesting: Mostly flat, with shallow validation checks; the extra block adds unnecessary nesting. Clarity of intent: Descriptive names and documentation clearly explain non-owning credential semantics, while the unused temperature calculation obscures retain()'s purpose. Code length: Generally concise, with justified documentation and small methods, but the injected block adds needless length. Action granularity: Statements generally perform one action per line. Reading flow: Method ordering and consistent patterns support natural reading, but the temperature block's inconsistent indentation and irrelevant logic abruptly interrupt that flow.