--- Comment #23 from Vincent Hennebert <> 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.


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to