Long vs BigDecimal for Money: Ten Community Perspectives

Problem

When persisting monetary values in Java, developers must decide whether to use Long (or other integer types) or BigDecimal. The choice depends on required precision, range, and the nature of the data (e.g., fixed‑currency amounts vs. rates or fees).

Technical Options

1. Use Long (or int / short / byte )

Store the amount in the smallest currency unit (e.g., cents). This eliminates fractional parts, avoids rounding errors, and fits within the 64‑bit range of Long. Suitable when all values are whole units of the smallest currency denomination.

2. Use BigDecimal

Provides arbitrary‑precision decimal arithmetic, preserving exact fractional values. Recommended for calculations that require rounding control, such as interest, tax, exchange rates, or when the monetary unit may have more than two decimal places.

3. Combine Long and BigDecimal

Store fixed‑currency amounts (price, total) as Long (cents) for performance and simplicity, while using BigDecimal for rates, fees, or any value that needs higher precision.

4. Store as String

Represent the amount as a textual value (e.g., "123.45"). This avoids type‑specific limits but requires custom parsing, validation, and arithmetic logic, which can be error‑prone.

5. Protobuf representation

Protocol Buffers do not have a native BigDecimal type. Options are to encode the value as a string or define a custom message (e.g., separate fields for unscaled value and scale). The string approach is simple but may incur slight performance overhead.

6. Custom domain type

Create a wrapper class (e.g., Money) that encapsulates the chosen storage strategy and provides domain‑specific operations. This improves readability, enforces business rules, and isolates conversion logic.

Guidelines for Choosing a Type

Precision requirement : If calculations must retain exact decimal fractions, prefer BigDecimal or a custom type based on it.

Performance & storage : For high‑throughput systems where only whole cents are needed, Long (or smaller integer types) is more efficient.

Interoperability : When data is exchanged via Protobuf or other serialization formats, ensure the chosen representation can be mapped reliably (e.g., using string or a custom message).

Business semantics : A dedicated Money class can encode currency, rounding mode, and validation, reducing bugs across the codebase.