An amount read as "12.0" and one read as "12.00" compare as the same number. They do not satisfy BigDecimal.equals. Replacing a comparison in one line therefore may leave a separate lookup problem in a HashMap.
Reproduce both answers in one class
This original exercise keeps decimal inputs as strings so their intended representation is explicit. Save it as DecimalIdentity.java:
import java.math.BigDecimal;
import java.util.HashMap;
import java.util.Map;
public class DecimalIdentity {
public static void main(String[] args) {
BigDecimal quoted = new BigDecimal("12.0");
BigDecimal imported = new BigDecimal("12.00");
Map<BigDecimal, String> labels = new HashMap<>();
labels.put(quoted, "standard amount");
System.out.println("numeric=" + (quoted.compareTo(imported) == 0));
System.out.println("equals=" + quoted.equals(imported));
System.out.println("lookup=" + labels.get(imported));
}
}
The expected output is:
numeric=true
equals=false
lookup=null
Oracle's BigDecimal reference, checked October 24, 2026, defines equals using both value and scale. Here the scales are 1 and 2. compareTo compares their numeric values. A hash-based map uses key equality, so using compareTo elsewhere does not change this map's key behavior.
Run java -version and javac -version to identify the installed tools. With a JDK available, use javac DecimalIdentity.java followed by java DecimalIdentity. This complete example produced the three lines above under Microsoft OpenJDK 21.0.11 during preparation. Check it in your project's environment before applying a larger change.
Choose the collection rule deliberately
If scale records meaningful information, preserve it and accept that the keys differ. The fact that both quantities are twelve does not decide whether the application should merge them.
If the application explicitly defines keys by numeric value alone, one option is a canonical key function applied at every insertion and lookup:
static BigDecimal amountKey(BigDecimal value) {
return value.stripTrailingZeros();
}
Use labels.put(amountKey(quoted), "standard amount") and labels.get(amountKey(imported)) with a fresh map. Both canonical inputs become the same key, so the expected lookup is standard amount. Applying the function only at lookup will not fix entries stored under the old representation. Existing persisted keys or maps need a separate migration decision.
Canonicalization can produce a negative scale, such as for values ending in integer zeros, and it discards the distinction between the original decimal representations. Keep display formatting and any source representation separately when those matter. Do not normalize every decimal in the application simply to repair this one map.
Ask ChatGPT to preserve the chosen meaning
Review this Java BigDecimal comparison and HashMap lookup.
JDK version, complete class and actual output: [PASTE]
What scale means in this application: [EXPLAIN]
Key identity rule: [NUMERIC VALUE ONLY / VALUE AND SCALE]
Explain compareTo, equals and map lookup separately using 12.0
and 12.00. Do not convert amounts to double or invent rounding.
If numeric-only keys are approved, show one canonical key function
used at both insertion and lookup. Explain existing-key migration
and what representation information normalization discards.
Return a small diff and expected outputs; identify any actual runs.
For a broader change, the code-review guide helps keep a finding tied to a reproduction. Finish this fix by checking insertions and lookups together, including two equal numeric values with different scales and one genuinely different amount.