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 a, String c) {
this.prototype = d(a);
this.bytes = prototype.getDigestLength();
this.toString = checkNotNull(c);
this.supportsClone = a(prototype);
}
MessageDigestHashFunction(String d, int f, String g) {
this.toString = checkNotNull(g);
this.prototype = d(d);
int h = prototype.getDigestLength();
checkArgument(
f >= 4 && f <= h, "bytes (%s) must be >= 4 and < %s", f, h);
this.bytes = f;
this.supportsClone = a(prototype);
}
private static boolean a(MessageDigest i) {
try {
Object j = i.clone();
return true;
} catch (CloneNotSupportedException e) {
return false;
}
}
@Override
public int b() {
return bytes * Byte.SIZE;
}
@Override
public String c() {
return toString;
}
private static MessageDigest d(String k) {
try {
return MessageDigest.getInstance(k);
} catch (NoSuchAlgorithmException e) {
throw new AssertionError(e);
}
}
@Override
public Hasher e() {
if (supportsClone) {
try {
return new MessageDigestHasher((MessageDigest) prototype.clone(), bytes);
} catch (CloneNotSupportedException e) {
// falls through
}
}
return new MessageDigestHasher(d(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 l, int m, String n) {
this.algorithmName = l;
this.bytes = m;
this.toString = n;
}
private Object a() {
return new MessageDigestHashFunction(algorithmName, bytes, toString);
}
private static final long serialVersionUID = 0;
}
Object f() {
return new SerializedForm(prototype.getAlgorithm(), bytes, toString);
}
private void g(ObjectInputStream o) 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 p, int q) {
this.digest = p;
this.bytes = q;
}
@Override
protected void a(byte b) {
b();
digest.update(b);
}
@Override
protected void a(byte[] b, int r, int s) {
b();
digest.update(b, r, s);
}
@Override
protected void a(ByteBuffer t) {
b();
digest.update(t);
}
private void b() {
checkState(!done, "Cannot re-use a Hasher after calling hash() on it");
}
@Override
public HashCode c() {
b();
done = true;
return (bytes == digest.getDigestLength())
? HashCode.fromBytesNoCopy(digest.digest())
: HashCode.fromBytesNoCopy(Arrays.copyOf(digest.digest(), bytes));
}
}
}
Run 1
This code is extremely obfuscated. Method names like 'a', 'b', 'c', 'd', 'e', 'f', 'g' and parameter names like 'a', 'c', 'd', 'f', 'g', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't' provide zero semantic meaning, making intent completely ambiguous. While structure follows standard class organization and nesting is relatively flat, the meaningless identifiers destroy clarity. The code appears deliberately minified - likely reverse-engineered or obfuscated - sacrificing all readability. Even the serialization logic and method purpose require significant effort to decipher. Code length is reasonable, but action granularity suffers from single-letter updates and checks. Reading flow is severely impaired as every method call requires mental mapping of meaningless names to their actual function. This represents the worst case of technically-valid but practically-unreadable Java code.
Run 2
The code is severely obfuscated due to single-letter method and parameter names (a, b, c, d, f, g, etc.), which completely obscures intent and makes the logic impossible to follow without deep inspection. The class has poor structure: helper methods are arbitrarily named and scattered, constructors have ambiguous parameters (String a, String c, int f, String g), and there is no logical grouping. Nesting is moderate but the unintelligible naming destroys comprehension. Action granularity is reasonable (one action per line), but this does not compensate for the lack of semantic naming. The reading flow is unnatural because the reader must constantly cross-reference definitions to understand what any function does. Overall, while the original logic may be sound, the deliberate renaming of all identifiers into meaningless symbols makes this code nearly unreadable and unmaintainable.
Run 3
The code is heavily obfuscated with single-letter method names (a, b, c, d, e, f, g) and single-letter parameters (a, c, d, f, g, i, j, k, l, m, n, o, p, q, r, s, t). This destroys clarity of intent and makes the reading flow extremely difficult. While the structure has some logical organization with separate classes for serialization and hashing, the abstraction is undermined by cryptic naming. Action granularity is mostly reasonable, and nesting is not extreme, but the code is unnecessarily difficult to understand. The original Guava code uses descriptive names; this obfuscated version fails to communicate purpose or function, making it effectively unreadable despite its relatively flat control flow and standard Java idioms.
Run 1
Code Structure: The adapter, serialization helper, and hasher are logically separated, with consistent formatting. Nesting: Mostly shallow; the clone fallback adds only modest nesting. Clarity of intent: Descriptive class and field names, comments, and validation messages help, but single-letter method and parameter names severely obscure operations, especially overloaded methods and serialization hooks. Code length: Generally concise, although constructor repetition and an unused clone-result variable add minor noise. Action granularity: Statements mostly perform one action per line; the final conditional expression combines digest generation, optional truncation, and wrapping but remains manageable. Reading flow: Member grouping and straightforward control flow support reading, while cryptic calls such as b(), d(d), and a(prototype) force readers to repeatedly consult definitions.
Run 2
Code Structure: Logically organized into the hash-function adapter, serialization helper, and digest hasher, with focused methods. Nesting: Generally shallow; only the clone fallback adds modest nesting. Clarity of intent: Class names, fields, and comments help, but single-letter method and parameter names substantially obscure operations, overload meanings, and serialization intent. Code length: Mostly concise, with reasonable delegation and little unnecessary code, although the unused clone-result variable adds noise. Action granularity: Typically one action per line; the final ternary combines digest generation, optional truncation, and conversion into a denser expression. Reading flow: Consistent formatting and sensible grouping support navigation, but readers must repeatedly infer what methods such as a(), b(), and d() do. Overall, strong structural readability is undermined by pervasive ambiguous naming.
Run 3
Code Structure: Logically organized into the hash-function adapter, serialization helper, and digest hasher, with focused methods. Nesting: Mostly shallow; the clone fallback adds only modest nesting. Clarity of intent: The primary weakness is pervasive single-letter method and parameter naming, which obscures operations, overload distinctions, and serialization-related intent. Descriptive class and field names, documentation, and error messages partially compensate. Code length: Generally concise, with reasonable constructor and update-method repetition, although the unused clone-result variable adds noise. Action granularity: Most statements perform one action per line; the final ternary combines digest generation, optional truncation, and wrapping but remains manageable. Reading flow: Conventional Java layout and grouping support navigation, but cryptic calls such as b(), c(), and d(d) repeatedly interrupt comprehension.