Source code
package com.google.common.hash;
import static com.google.common.base.Preconditions.checkArgument;
import static com.google.common.base.Preconditions.checkNotNull;
import static com.google.common.base.Preconditions.checkState;
import com.google.errorprone.annotations.Immutable;
import java.io.InvalidObjectException;
import java.io.ObjectInputStream;
import java.io.Serializable;
import java.nio.ByteBuffer;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
/**
* {@link HashFunction} adapter for {@link MessageDigest} instances.
*
* @author Kevin Bourrillion
* @author Dimitris Andreou
*/
@Immutable
final class MessageDigestHashFunction extends AbstractHashFunction implements Serializable {
@SuppressWarnings("Immutable") // cloned before each use
private final MessageDigest prototype;
private final int bytes;
private final boolean supportsClone;
private final String toString;
MessageDigestHashFunction(String algorithm, String to) {
this.prototype = get(algorithm);
this.bytes = prototype.getDigestLength();
this.toString = checkNotNull(to);
this.supportsClone = supports(prototype);
}
MessageDigestHashFunction(String algorithm2, int byt, String to2) {
this.toString = checkNotNull(to2);
this.prototype = get(algorithm2);
int max = prototype.getDigestLength();
checkArgument(
byt >= 4 && byt <= max, "bytes (%s) must be >= 4 and < %s", byt, max);
this.bytes = byt;
this.supportsClone = supports(prototype);
}
private static boolean supports(MessageDigest dig) {
try {
Object unu = dig.clone();
return true;
} catch (CloneNotSupportedException e) {
return false;
}
}
@Override
public int bit() {
return bytes * Byte.SIZE;
}
@Override
public String to() {
return toString;
}
private static MessageDigest get(String algorithm3) {
try {
return MessageDigest.getInstance(algorithm3);
} catch (NoSuchAlgorithmException e) {
throw new AssertionError(e);
}
}
@Override
public Hasher new2() {
if (supportsClone) {
try {
return new MessageDigestHasher((MessageDigest) prototype.clone(), bytes);
} catch (CloneNotSupportedException e) {
// falls through
}
}
return new MessageDigestHasher(get(prototype.getAlgorithm()), bytes);
}
private static final class SerializedForm implements Serializable {
private final String algorithmName;
private final int bytes;
private final String toString;
private SerializedForm(String algorithm4, int byt2, String to3) {
this.algorithmName = algorithm4;
this.bytes = byt2;
this.toString = to3;
}
private Object read() {
return new MessageDigestHashFunction(algorithmName, bytes, toString);
}
private static final long serialVersionUID = 0;
}
Object write() {
return new SerializedForm(prototype.getAlgorithm(), bytes, toString);
}
private void read(ObjectInputStream str) throws InvalidObjectException {
throw new InvalidObjectException("Use SerializedForm");
}
/** Hasher that updates a message digest. */
private static final class MessageDigestHasher extends AbstractByteHasher {
private final MessageDigest digest;
private final int bytes;
private boolean done;
private MessageDigestHasher(MessageDigest dig2, int byt3) {
this.digest = dig2;
this.bytes = byt3;
}
@Override
protected void upd(byte b) {
check();
digest.update(b);
}
@Override
protected void upd(byte[] b, int off, int len) {
check();
digest.update(b, off, len);
}
@Override
protected void upd(ByteBuffer byt4) {
check();
digest.update(byt4);
}
private void check() {
checkState(!done, "Cannot re-use a Hasher after calling hash() on it");
}
@Override
public HashCode has() {
check();
done = true;
return (bytes == digest.getDigestLength())
? HashCode.fromBytesNoCopy(digest.digest())
: HashCode.fromBytesNoCopy(Arrays.copyOf(digest.digest(), bytes));
}
}
}
Run 1
The code is generally readable and well-structured. It uses clear naming, reasonable separation of concerns, and appropriate comments. However, there are inconsistencies that reduce clarity: method names are shortened (e.g., 'bit', 'to', 'new2', 'upd', 'has', 'read', 'write'), which obscures intent compared to standard Java conventions. Some parameter names are awkwardly suffixed (algorithm2, byt, to2, algorithm3, algorithm4, byt2, to3, dig2, byt3, byt4) which diminishes readability. The cloning fallback logic in 'new2' is slightly tangled due to the empty catch block. Nesting is shallow overall, and each action is generally on its own line, which is good. The code is concise but not overly compressed. Overall, it's understandable to someone familiar with the domain, but the abbreviated naming and parameterization choices reduce its readability compared to the original Guava source, which would use clearer names.
Run 2
The code has clear structure and separation of concerns, but it suffers from poor naming conventions and inconsistent method signatures that severely impact readability. The use of abbreviated names like `bit()`, `to()`, `new2()`, `upd()`, `has()`, and parameters like `unu`, `byt`, `to2`, `algorithm3`, `dig2`, `byt3`, `byt4` obscures intent and makes the code feel unnatural. While nesting is minimal and action granularity is mostly one operation per line, the reading flow is disrupted by these cryptic names and odd parameter numbering. The class-level structure is logical, but the method names don't follow typical Java conventions, making it difficult to understand their purpose without deep inspection. The serialization handling is standard but the `read()` and `write()` methods are also poorly named. Overall, the code appears to be intentionally obfuscated or was refactored with automated tools that stripped meaningful names, reducing what would otherwise be a well-structured implementation to a confusing one.
Run 3
The code has logical structure but readability is severely hurt by cryptic naming and inconsistent conventions. Method names like 'bit()', 'to()', 'new2()', 'upd()', 'has()', and 'read()' obscure intent. Parameters like 'algorithm2', 'byt', 'to2', 'algorithm3', 'dig2', 'byt3' suggest copy-paste or obfuscation. The class has redundant constructors and serialization logic is awkwardly placed. Nesting is shallow and actions are generally one-per-line, which helps, but the poor naming and ambiguous method overloads make the reading flow disorganized. The code is not deeply nested or overly long, but clarity of intent is low due to meaningless identifiers and missing documentation for many methods.
Run 1
Code Structure: Clear separation between the hash-function adapter, serialization proxy, and digest hasher. Nesting: Mostly shallow, with only modest nesting in cloning and exception handling. Clarity of intent: Class names, fields, and comments communicate the overall purpose, but abbreviated methods such as bit(), to(), new2(), upd(), and has(), plus numbered parameters, obscure individual operations. Generic read/write names also hide serialization intent. Code length: Methods are concise and largely purposeful, though the unused clone result adds noise. Action granularity: Statements generally perform one action per line; the final ternary combines digest calculation, optional truncation, and conversion but remains manageable. Reading flow: Organization is natural, progressing from initialization through factory and serialization logic to hashing operations. Inconsistent naming and constructor assignment order interrupt an otherwise straightforward flow.
Run 2
1. Code Structure: Logically organized into digest setup, hasher creation, serialization, and a nested hasher implementation. 2. Nesting: Mostly shallow; the clone fallback adds only modest nesting. 3. Clarity of intent: The adapter purpose is documented, but abbreviated methods such as new2, upd, and has, numbered parameters, and the unused variable unu obscure meaning. Renamed serialization methods also conceal their intended lifecycle roles. 4. Code length: Reasonably concise, with short methods; constructor duplication and repeated state checks add minor repetition. 5. Action granularity: Statements generally perform one action per line, though the final ternary combines digest generation, truncation, and wrapping. 6. Reading flow: Consistent indentation and grouping support navigation, but cryptic naming and the inconsistent validation message ('<' despite an inclusive upper bound) interrupt understanding.
Run 3
Code Structure: Well organized into constructors, digest helpers, a serialization proxy, and a dedicated hasher class. Nesting: Mostly shallow; the clone fallback adds only modest nesting. Clarity of intent: Class documentation and recognizable MessageDigest operations help, but abbreviated or altered names such as bit, new2, upd, has, byt, and algorithm2 obscure method roles and parameters. Code length: Generally concise, with reasonable overloads and little unnecessary repetition; the unused clone-result variable adds minor noise. Action granularity: Statements generally perform one action per line, making state changes and digest updates easy to follow. Reading flow: Formatting and grouping support sequential reading, although cryptic naming and generic serialization method names interrupt comprehension. The argument-check message also says '<' while the condition permits equality, reducing clarity.