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) {
final int a = 1;
final int b = -1;
if (credential == (a + b)) {
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 clear intent with good documentation and a logical structure, but several readability issues exist. The constructor contains a bizarre and confusing null-check pattern (`int a = 1; int b = -1; if (credential == (a + b))`) which obscures what should be a simple `if (credential == 0)` check. The `touch(Object hint)` method ignores its parameter and returns `this` without calling `super.touch(hint)`, which is misleading and probably incorrect. The class is relatively flat with minimal nesting, and methods are concise with clear action granularity. However, the strange variable names and redundant arithmetic add unnecessary cognitive load. The javadoc is well-written and explains the purpose clearly, but the implementation details undermine the overall readability.
Run 2
The code is generally well-structured with clear class purpose and documentation. However, several readability issues lower the score. The constructor uses an obscure anti-pattern: `final int a = 1; final int b = -1; if (credential == (a + b))` instead of simply checking `credential == 0`, which obscures intent. The `touch(Object hint)` method returns `this` without calling `super.touch(hint)`, potentially causing subtle behavioral inconsistency despite consistent typing. Methods are concise and focused, but some boilerplate (repeated retain/touch overrides) adds length without adding clarity. The class has flat nesting, good action granularity, and follows a logical reading flow. Overall, the code is maintainable but could be improved with clearer null-pointer validation and reduced boilerplate.
Run 3
The code is generally readable with clear structure, good documentation, and logical organization. The class has a single responsibility and methods are concise. However, readability is slightly reduced by the constructor's zero-check: using `final int a = 1; final int b = -1;` and comparing `credential == (a + b)` obscures the intent. A direct `credential == 0` check with a comment would be clearer. Nesting is minimal and action granularity is appropriate. The reading flow is natural, and the Javadoc comments effectively explain the purpose and BoringSSL-specific nature. The `touch(Object hint)` method returning `this` without calling `super.touch(hint)` is slightly ambiguous but acceptable in context. Overall, this is well-structured code with minor clarity improvements possible.
Run 1
Code Structure: The class is logically organized into fields, construction, accessors, reference-counting methods, and cleanup. Nesting: Methods are flat, with only simple guard conditions. Clarity of intent: Descriptive names and documentation clearly explain the non-owning wrapper and external lifetime management. However, checking zero through variables a and b and the expression (a + b) unnecessarily obscures a straightforward validation. Code length: The implementation is compact overall, though those temporary variables add avoidable lines. Action granularity: Each statement performs one clear action, making individual operations easy to follow. Reading flow: Method ordering and consistent formatting support natural reading; the arithmetic zero check interrupts that flow, and a blank line between the package declaration and imports would improve presentation.
Run 2
Code Structure: Fields, constructor, accessors, and lifecycle methods are logically organized. Nesting: Shallow conditionals keep execution paths easy to follow. Clarity of intent: Descriptive names and documentation clearly explain non-owning behavior and external lifetime management; however, using a + b instead of 0 obscures a straightforward pointer validation. Code length: Generally concise, with short methods; the two artificial constants add unnecessary length. Action granularity: Each statement performs one clear action, without compressed or compound operations. Reading flow: Consistent formatting and conventional method organization support natural reading, though the constructor's arithmetic detour briefly interrupts it.
Run 3
Code Structure: Fields, constructor, accessors, and lifecycle overrides are logically organized. Nesting: Flat methods with only simple guards make control flow easy to follow. Clarity of intent: Descriptive names and documentation clearly explain non-owning behavior and external lifetime management. However, using arbitrary variables a and b to express zero obscures an otherwise straightforward pointer check. Code length: Mostly concise; the constructor adds unnecessary declarations, while the repetitive overrides serve the API. Action granularity: Each statement performs a single action, with no crowded multi-statement lines. Reading flow: Consistent formatting and predictable method ordering support natural reading, though the arithmetic detour in the constructor briefly interrupts it.