Source code
package io.netty.handler.codec.quic;
import io.netty.util.concurrent.FastThreadLocal;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec; import java.nio.ByteBuffer;
import java.security.InvalidKeyException; import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.util.Arrays; final class Hmac {
private static final String ALGORITHM = "HmacSHA256";
// Two independent keys so that CID signing and reset-token signing are
// cryptographically decoupled: an observer cannot derive one output from
// the other even when both use the same input value (RFC 9000 §21.11).
private static final byte[] CID_KEY = new byte[32];
private static final byte[] TOKEN_KEY = new byte[32];
static {
SecureRandom rng = new SecureRandom();
rng.nextBytes(CID_KEY); rng.nextBytes(TOKEN_KEY);
}
private static final FastThreadLocal<Mac> CID_MACS = new FastThreadLocal<Mac>() { @Override
protected Mac initialValue() {
return newMac(CID_KEY); } }; private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac initialValue() { return newMac(TOKEN_KEY); }
};
private static Mac newMac(byte[] key) {
try {
SecretKeySpec keySpec = new SecretKeySpec(key, ALGORITHM); Mac mac = Mac.getInstance(ALGORITHM); mac.init(keySpec); return mac; } catch (NoSuchAlgorithmException | InvalidKeyException exception) { throw new IllegalStateException(exception); }
}
private static ByteBuffer sign(Mac mac, ByteBuffer input, int outLength) { mac.reset();
mac.update(input);
byte[] signBytes = mac.doFinal(); if (signBytes.length != outLength) { signBytes = Arrays.copyOf(signBytes, outLength);
} return ByteBuffer.wrap(signBytes);
} static ByteBuffer signCid(ByteBuffer input, int outLength) {
return sign(CID_MACS.get(), input, outLength);
}
static ByteBuffer signToken(ByteBuffer input, int outLength) {
return sign(TOKEN_MACS.get(), input, outLength); }
private Hmac() { }
}
Run 1
The code has a clear purpose (HMAC helper) and uses some good practices like comments and static constants, but it is severely undermined by formatting and structural issues. Multiple statements are crammed onto single lines, and unrelated class members (like the FastThreadLocal anonymous classes) are tangled together, hurting logical organization and reading flow. Deeply nested anonymous classes, combined with horizontal crowding, make the code hard to follow. Although individual methods are short, the intentional compression to save vertical space reduces clarity. The comment explaining key separation is helpful, but it does not compensate for the inconsistent indentation and lack of whitespace between logical blocks.
Run 2
The code has mixed readability. It has clear intent with comments and separates concerns, but the formatting severely hurts readability: multiple statements are crammed onto single lines, try-catch blocks are compressed, indentation is inconsistent, and thread-local anonymous class declarations are hard to parse. Variable names like CID_KEY and TOKEN_KEY are clear, and methods are logically organized, but the overall structure feels tangled and dense. Action granularity is low in many places, making the code harder to scan. The use of static final fields and separation of signing routes is good, but the presentation forces the reader to work hard to extract meaning. Overall, it's functional but not cleanly formatted.
Run 3
The code is poorly readable due to several significant issues. Multiple statements are crammed onto single lines, especially in the static initializers and catch blocks, making it hard to follow. There is inconsistent indentation and spacing (e.g., fields with odd alignment vs inline thread locals). Nested or multi-action lines hide logic — for example, the sign() method has a conditional and copy operation all on one line. The FastThreadLocal anonymous classes are compressed, harming clarity. Imports are jumbled with a class declaration after them on the same line, a major structural flaw. Method bodies lack whitespace around logical blocks, and the single-line if and catch blocks reduce readability, especially for error handling. While names and some comments are helpful, the overall structure, formatting, and action granularity severely undercut the readability.
Run 1
1. Code Structure: Logically organized around key initialization, thread-local MAC instances, and shared signing helpers, but cramped formatting obscures boundaries. 2. Nesting: Shallow overall; anonymous classes and try/catch introduce manageable nesting. 3. Clarity of intent: Descriptive names, a clear algorithm constant, and the key-separation comment make the purpose understandable. 4. Code length: Concise, with shared helpers avoiding duplication; however, excessive compression reduces readability rather than improving it. 5. Action granularity: Multiple imports, assignments, method calls, returns, and declarations share lines, making individual actions harder to scan. 6. Reading flow: The conceptual progression is natural, but inconsistent indentation, inline braces, and adjacent method declarations repeatedly interrupt reading.
Run 2
Code Structure: Sensible separation of key initialization, MAC creation, shared signing logic, and purpose-specific entry points, but cramped formatting obscures these boundaries. Nesting: Shallow overall; anonymous classes and exception handling add only modest complexity. Clarity of intent: Descriptive constants and method names, plus the key-separation comment, make the purpose clear. Code length: Concise without substantial duplication, although excessive compression hurts readability. Action granularity: Multiple imports, statements, declarations, and closing braces share lines, making individual actions harder to distinguish. Reading flow: The conceptual progression is natural, but inconsistent indentation and abrupt transitions between methods and fields interrupt scanning.
Run 3
Code Structure: Constants, key initialization, thread-local MACs, and signing helpers are logically organized, but compressed declarations obscure their boundaries. Nesting: Shallow overall; anonymous classes and exception handling add only modest complexity. Clarity of intent: Descriptive names and the key-separation comment clearly explain the purpose. Code length: Appropriately short with shared helpers avoiding duplication, though excessive compression sacrifices readability. Action granularity: Multiple imports, initialization calls, declarations, and operations share lines, making individual actions harder to scan. Reading flow: The conceptual sequence is natural, but inconsistent line breaks, inline annotations, and crowded closing braces repeatedly interrupt it.