Long vs BigDecimal for Monetary Values: Which Is Safer?

Problem

Someone posted an interesting question online: should monetary amounts be stored using Long or BigDecimal? In one team the group leader prefers BigDecimal for safety, the director argues that Long avoids issues, and developers claim that Long is more convenient.

Community Proposals

Long

Interpretation: The amount is stored in cents, so there is no decimal point and thus no precision issue. The range of Long is also sufficient.

BigDecimal

Interpretation: Everyone uses it; BigDecimal exists for precise calculations. Using Long is considered unprofessional and less adaptable.

Long and BigDecimal

Interpretation: Adults don’t make a single choice; they use both. Use Long for amounts and prices, and BigDecimal for exchange rates or fees that require more decimal places.

String

Interpretation: Anything can be stored as a string, but all processing rules must be written manually; it’s a skill for experts.

Protobuf

Interpretation: Outside of a framework, proposals are meaningless. Protobuf does not have a native BigDecimal type; you could use a string or a custom type, but performance may suffer slightly.

Custom Type

Interpretation: A good candidate for architects. Code must not only run without errors; the design should naturally reflect business requirements, be easy to understand, extend, and maintain.

Follow the Leader

Interpretation: When a leader (even a famous one) gives instructions, it’s not a technical issue; you should obey but also protect yourself.

Ask AI

Interpretation: Keep up with the trend. As a tech enthusiast, you should leverage advanced productivity tools; a large language model can answer the question perfectly.

Cost‑Saving

Interpretation: Frugality is a virtue. For a few hundred‑yuan transaction, you don’t need Long; int, short, or even byte can satisfy the requirement.

Confused

Interpretation: Is the specific chip unable to perform floating‑point operations? Do different CPUs implement floating‑point differently? Should the programming language handle this automatically? The author admits a lack of understanding and asks for expert help.

Fundamental Issue

The core of the debate is precision of decimal numbers. Sometimes a division is non‑terminating, e.g., 10 ÷ 3. Other times the problem stems from how floating‑point types (float, double) represent numbers using scientific notation, which can lead to infinite binary fractions—like JavaScript’s 0.1 + 0.2 not equaling 0.3.

To avoid such issues, developers have devised many approaches. Both Long and BigDecimal ultimately store values as integers; Long implicitly fixes the decimal point, while BigDecimal explicitly defines it.

For example, when using Long to represent price, the system may agree that the unit is cents, so 9999 means ¥99.99. With BigDecimal, you would write new BigDecimal("99.99") to represent the same amount.

Regardless of the type, any division that does not terminate introduces precision loss.

Solution

In practice, the best practice for handling monetary values is to use a type like BigDecimal, because it provides exact decimal arithmetic essential for financial calculations. BigDecimal can represent and compute decimals precisely, allowing you to define the scale and choose rounding modes that meet financial requirements.

Using Long (typically storing amounts in cents) is also possible and avoids floating‑point errors, but it requires manual management of the decimal point, especially when converting currencies or performing calculations that involve fractions.

For instance, with Long you must remember whether the stored value is in cents or yuan, and you often need an extra conversion step to display the amount in a user‑friendly format.

Therefore, while Long can represent amounts accurately, BigDecimal offers better readability, ease of use, and reduces the risk of manual decimal‑point errors, making it the safer and more flexible choice for precise monetary computation.

Other approaches such as using String or custom classes are possible but require additional rule‑writing, are error‑prone, and are generally not recommended when a well‑tested library like BigDecimal exists.

That concludes the main content of this article.