2

The current way of knowing if a BigDecimal is greater than another is

bigDecimal.compareTo(otherBigDecimal) > 0

(or one.compareTo(another) == 1), but I find it too clunky and unexpressive. bigDecimal.isGreaterThan(otherBigDecimal) is easier to understand.

For people who are used to Java and know how compareTo() works, the present way makes sense. For someone who has OO programming experience other than Java, I assume they would have to look at the API to understand what the magic numbers are for in this operation.

I saw no attempt in Guava or Apache's NumberUtils to fix this and we are already about to reach Java 9.

In gist, what I'm asking is, is there any legitimate reason that this clunky way of comparing BigDecimals has not been redone? (Other than "There's so much to fix in Java, this just is not a priority.")

lemuel
  • 131

1 Answers1

2

Aside the actual:

There's so much to fix in Java, this just is not a priority.

There is another one. If you have a isGreaterThan, it means that you will also want to have isLesserThan. This would solve your needs, but not the needs of the developers who will rather search for isSuperiorTo and isInferiorTo and be disappointed when auto-completion doesn't show the corresponding method.

More importantly, what do you do with compareTo? Do you remove it? If yes, this will break all previously written code which uses this method. If you keep it, you now have two redundant methods, and two different ways to perform an action, and you have forum threads where people argue which one of those two approaches is better.

Another approach would be to use an enum:

bigDecimal.compareTo(otherBigDecimal) == Comparison.firstIsBigger;

However, this change is not backwards compatible either.

A very similar issue concerns JUnit-style libraries. There is always a choice between including more and more assertion helpers, or keep the interface light and let the users ask why their favorite method was not implemented. Basically, a unit testing framework has to include assert(something) exclusively. Other helpers can be convenient, but if you try to respond to every need of every user, the framework will end with thousands of methods, and that would be unusable.

Community
  • 1
Arseni Mourzenko
  • 137,583