Miscellaneous minor patches: javadoc typos, javac warnings, etc.

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Wed Nov 9 18:40:55 UTC 2011

Hello Phil

Le 09/11/11 18:37, Phil Race a écrit :
> Please do register on 2d-dev and propose the 2D changes there.
Registration done, I will post in a few minutes.

> The hashcode change
> definitely needs discussion, I think there may be views on the NaN comparison 
> as my
> understanding is that this is supposed to always be not equal.
The proposed change is consistent with the java.lang.Double.equals(Object) 
behavior. It seems to me the only way to be compliant with the reflexivity 
contract documented in Object.equals javadoc, apart doing a "if (other == this) 
return true" check. Maybe whatever full compliance with Object.equals is 
strongly desired or not can be a question for the core group? I would like to 
note that incomplete compliance may be a risk when AffineTransform (or any other 
object) is used as keys in Hashtable: in current implementation, if an 
AffineTransform object with at least one NaN value is added in a Hashtable, it 
is impossible to remove it by a call to Hashtable.remove(Object) (we can still 
remove it by Iterator.remove()). (Note: my example uses Hashtable instead of 
HashMap because HashMap has a clever implementation that check for object 
references before to invoke Object.equals, which invalidate my argument. However 
not all implementations are that safe).

> PS this is such an unrelated set of changes, I am not sure it should be under 
> one CR, even for 2D.
Actually this is 8 distinct change sets, but webrev merged all my change sets in 
a single one. Since it is the first time I'm using webrev, I'm probably not 
using it in the right way. But I still have the 8 distinct changes set on my 
local Mercurial clone, so I can probably recreate new webrev pages if I learn 
how to use webrev better...



More information about the core-libs-dev mailing list