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() {
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 severe readability issues. Fields are declared on the same line, Javadocs are interleaved with code, and multiple statements are crammed onto single lines (e.g., constructor logic, if-blocks, and method returns). The opening brace is placed at the end of a line containing other code, making structure hard to follow. While the class's purpose is clear from the header comment, the formatting obscures intent and makes the flow disorganized. Nesting is minimal, but action granularity is poor—many lines combine multiple actions. Overall, the logic is simple, but the physical layout significantly harms readability despite the class being conceptually straightforward.
Run 2
The code has severe readability issues. The class structure is logical but the formatting is highly inconsistent: multiple statements and fields are on the same line, Javadoc and code are mixed on single lines, and several methods are compacted together without line breaks. This makes the code difficult to scan and understand. Nesting is minimal, which is good, and the intent is mostly clear from the class name and comments. However, the action granularity is poor, with multiple actions per line in several places (e.g., field declarations, constructor checks, method chains). The reading flow is disorganized due to the lack of standard spacing and alignment. While the code is concise, it is unnecessarily dense and violates typical Java style conventions. The score reflects the structural clarity of the class hierarchy and method names but is heavily penalized for formatting and readability.
Run 3
The code has severe readability issues. Formatting destroys the logical structure: multiple fields and methods are crammed onto single lines, making the class hard to scan. Nesting is minimal but obscured by the lack of line breaks. Intent is reasonably clear from the Javadoc, but the implementation fails to support it at a glance. Code length is acceptable, but action granularity is poor, with several statements and methods sharing lines. Reading flow is disorganized due to erratic line breaks and inconsistent indentation. While the logic itself is simple, the formatting makes it difficult to parse and review. Properly formatted, this could easily be a 15+; as written, it is nearly unreadable.
Run 1
Code Structure: The class has a logical arrangement of fields, constructor, accessors, and lifecycle methods, but compressed formatting obscures boundaries. Nesting: Minimal nesting makes the control flow easy to follow. Clarity of intent: Descriptive names and useful documentation clearly explain non-owning behavior and external lifetime management. Code length: The implementation is concise, with little unnecessary code. Action granularity: Multiple field declarations, statements, annotations, and method boundaries share lines, reducing readability. Reading flow: Inconsistent line breaks and braces, plus documentation attached to a field declaration, interrupt otherwise straightforward reading. Conventional Java formatting would substantially improve readability without changing the logic.
Run 2
Code Structure: The class has a logical arrangement of fields, constructor, accessors, and lifecycle methods, but compressed formatting obscures boundaries. Nesting: Shallow conditionals make the logic easy to follow. Clarity of intent: Descriptive names and useful documentation clearly explain the non-owning wrapper and externally managed lifetime. Code length: The implementation is concise, with little unnecessary code. Action granularity: Multiple field declarations, statements, annotations, and method boundaries share lines, reducing scanability. Reading flow: Inconsistent indentation and placement of braces and documentation interrupt otherwise natural progression. Overall, the simple logic and clear purpose are undermined by poor formatting.
Run 3
Code Structure: The class has a logical arrangement of fields, constructor, accessors, and reference-counting methods, but inconsistent formatting blurs their boundaries. Nesting: Minimal nesting keeps control flow easy to understand. Clarity of intent: Descriptive names and useful documentation clearly explain the wrapper's non-owning behavior and externally managed lifetime. Code length: The implementation is concise, with little unnecessary code. Action granularity: Multiple declarations, annotations, statements, and closing braces share lines, making individual operations harder to scan. Reading flow: Irregular line breaks and indentation interrupt an otherwise natural progression through the class. Overall, the simple design and clear intent provide reasonable readability, but compressed formatting significantly reduces it.