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...
Regards,
Martin
