JodaOrg/joda-money — pull request #45 by ffbit (2014-07-12 10:49:55+00:00)
Title: Adjusted the BigMoney#equals according to the BigDecimal implementation details

The current behaviour of the BigMoney#equals hurt me with an "equal" amounts in different BigDecimal representation as in the following example

![screen shot 2014-07-12 at 12 07 54 pm](https://cloud.githubusercontent.com/assets/1078842/3561245/f96ea47a-09b1-11e4-93d1-d0fd83e5ba98.png)

As stated in the [BigDecimal#equals javadocs](http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#equals\(java.lang.Object\))

> Compares this BigDecimal with the specified Object for equality. Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method).

So

![screen shot 2014-07-12 at 11 36 12 am](https://cloud.githubusercontent.com/assets/1078842/3561246/18f8c000-09b2-11e4-8ecd-ce3f772fba42.png)

According to the mentioned above, this pull request brings changes based on the [BigDecimal#compareTo](http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#compareTo\(java.math.BigDecimal\)) suggestions

> Compares this BigDecimal with the specified BigDecimal. Two BigDecimal objects that are equal in value but have a different scale (like 2.0 and 2.00) are considered equal by this method. This method is provided in preference to individual methods for each of the six boolean comparison operators (<, ==, >, >=, !=, <=). The suggested idiom for performing these comparisons is: (x.compareTo(y) 0), where is one of the six comparison operators.