Source code
package io.netty.handler.ssl;
import io.netty.internal.tcnative.SSLPrivateKeyMethod;
import io.netty.util.internal.UnstableApi;
import javax.net.ssl.SSLEngine;
/**
* Allow to customize private key signing / decrypting (when using RSA). Only supported when using BoringSSL atm.
*/
@UnstableApi
public interface OpenSslPrivateKeyMethod {
int SSL_SIGN_RSA_PKCS1_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA1;
int SSL_SIGN_RSA_PKCS1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA256;
int SSL_SIGN_RSA_PKCS1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA384;
int SSL_SIGN_RSA_PKCS1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA512;
int SSL_SIGN_ECDSA_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SHA1;
int SSL_SIGN_ECDSA_SECP256R1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP256R1_SHA256;
int SSL_SIGN_ECDSA_SECP384R1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP384R1_SHA384;
int SSL_SIGN_ECDSA_SECP521R1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP521R1_SHA512;
int SSL_SIGN_RSA_PSS_RSAE_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA256;
int SSL_SIGN_RSA_PSS_RSAE_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA384;
int SSL_SIGN_RSA_PSS_RSAE_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA512;
int SSL_SIGN_ED25519 = SSLPrivateKeyMethod.SSL_SIGN_ED25519;
int SSL_SIGN_RSA_PKCS1_MD5_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_MD5_SHA1;
/**
* Signs the input with the given key and returns the signed bytes.
*
* @param engine the {@link SSLEngine}
* @param signatureAlgorithm the algorithm to use for signing
* @param input the digest itself
* @return the signed data (must not be {@code null})
* @throws Exception thrown if an error is encountered during the signing
*/
byte[] sign(SSLEngine engine, int signatureAlgorithm, byte[] input) throws Exception;
/**
* Decrypts the input with the given key and returns the decrypted bytes.
*
* @param engine the {@link SSLEngine}
* @param input the input which should be decrypted
* @return the decrypted data (must not be {@code null})
* @throws Exception thrown if an error is encountered during the decrypting
*/
byte[] decrypt(SSLEngine engine, byte[] input) throws Exception;
}
Run 1
The code is well-structured as a concise interface definition. Constants are logically grouped and consistently formatted, though the list is long. The interface avoids unnecessary nesting and has a clear purpose: defining a custom private key method for SSL operations. Method signatures are concise with clear parameter names and return types. Javadoc comments effectively document intent and behavior. Reading flow is natural, with constants first, then methods, and clear documentation separating them. Minor deductions result from repetitive constant declarations and slight verbosity in Javadoc, but overall readability is high.
Run 2
The code is highly readable. It has a clear logical structure with a package declaration, imports, Javadoc, interface declaration, constants, and method signatures. The nesting is minimal—essentially flat. The intent is clear: define an interface for custom private key operations with documented methods. The length is concise; constants are repeated but unavoidable and aligned for readability. Action granularity is one constant per line, consistent and easy to scan. The reading flow is natural, moving from imports to type-level documentation, constants, then methods. Minor deductions: the long constant names make lines somewhat long, and the Javadoc for the interface could be slightly more descriptive, but overall this is excellent, idiomatic Java.
Run 3
The code is highly readable, concise, and well-structured. It defines a clear interface with self-descriptive constant names and clear method signatures. There is no nesting, each line is a single declaration, and the purpose is immediately evident. Javadoc comments provide concise parameter and return descriptions. The only minor drawback is that the import of SSLPrivateKeyMethod constants results in a long list of constant declarations, which some could find repetitive, but this is standard practice for exposing native constants in a public API and does not harm readability. Overall, it follows Java best practices and is easy for developers to understand.
Run 1
Code Structure: Well-organized interface with imports, algorithm constants, and two documented methods. Nesting: Flat, with no nested logic. Clarity of intent: Descriptive names and Javadocs clearly communicate signing and decryption responsibilities, although key selection is implicit and the introductory wording is informal. Code length: Concise for its purpose; repetitive constant aliases are reasonable API declarations. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural progression from configuration constants to operations, slightly hindered by the dense constant block and lack of spacing between package and imports. Grouping constants by algorithm family would improve scanning.
Run 2
Code Structure: Clearly organized interface with imports, algorithm constants, and two documented methods. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive names and parameter/return documentation make signing and decryption responsibilities clear, though the opening comment's RSA qualification is ambiguous and 'atm' is informal. Code length: Concise for its purpose; repetitive constants are justified by the API. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural progression from configuration constants to operations, with minor opportunities to improve spacing around imports and visually group algorithm families.
Run 3
Code Structure: Clearly organized interface with imports, algorithm constants, and two documented methods. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive names and Javadoc explain signing and decryption, though the introductory RSA wording could be clearer and the key source is implicit. Code length: Concise overall; the repetitive constants are appropriate for exposing supported algorithms. Action granularity: Each line contains a single declaration, making scanning straightforward. Reading flow: Natural progression from constants to operations, with minor improvements possible through separating imports and grouping constants by algorithm family.