https://issues.apache.org/bugzilla/show_bug.cgi?id=46962
--- Comment #23 from Vincent Hennebert <[email protected]> 2012-03-22 16:54:42 UTC --- Hi Alexios, (In reply to comment #21) > Vincent, thanks for looking at it. > > > * Why use Double.doubleToLongBits in equals methods to compare doubles > > (NumericProperty, PercentLength)? Why not just thisDouble == otherDouble? > > (One > > could also argue that some epsilon might be necessary, but this is another > > topic.) > > > Well, if we forget about the epsilon, the doubleToLongBits is the correct way > to check for equality two doubles. This is well explained in Effective Java by > Joshua Bloch, used in Double#compare, Double#equals and by all IDEs that > generate them and libraries like Apache commons-lang EqualsBuilder. Java > has double values for both 0.0 and -0.0, as well as the never equal > "not a number" (NaN). Those can't be checked with ==. > Have a look into the doubleToLongBits source and at the javadoc for > Double.equals(). Learning new things every day :-) Thanks for the pointers. > > * shouldn't the specVal field from Property also be tested for equality? > > It seems that currently this is not needed. The specVal is set by 3 > properties, > the FontShorthandProperty, the LineHeightProperty and the URIProperty. > None of them uses the cache, so currently it is not needed in the equality > tests. Ok, make sense. Still I'll modify the implementations of equals and hashCode in the URIProperty class as it makes explicit use of specVal. > Please tell me if you expect an updated patch. It's not necessary. Thanks, Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
