Was: "Re: [Geotools-devel] Assertions Failure is bringing down uDig trunk."
Jesse Eichar a écrit : > assert hashCode() == that.hashCode() : this; <------- This line is the error Should be fixed on trunk as of revision 28779, but the fix revealed a deeper problem. A few months ago, we defined explicitly hashCode() and equals(Object) contract in DirectPosition: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/geometry/DirectPosition.html#equals(java.lang.Object) The DirectPosition2D class was already existing prior the above addition. It is defined as below, in an attempt to act as a bridge between Java2D and GeoAPI: public class DirectPosition2D extends Point2D implements DirectPosition It was inheriting the Point2D.hashCode() implementation. But now that DirectPosition.hashCode() is explicitly defined, we have a clash between Point2D.hashCode() implementation and DirectPosition.hashCode() contract. There is no way to satisfy both in same time. Changing the DirectPosition.hashCode() contract is not a good option since it would make it more complicated, and even if we solved the Point2D case there is many other cases that could occur (JTS position, Java3D points, etc. - we can not satisfy them all). This clash is a problem because Point2D.equals(Object) is defined as below: if (other instanceof Point2D) { // do the comparaison } The problem would not occurs if it has been defined as below instead (i.e. if we require the exact same class): if (other!=null && other.getClass() == getClass()) { // do the comparaison } Reason: if the object to compare are of the exact same class, we know that their hashCode() implementations are identical. If they are not equals, we don't have this garantee. "This" could use the Point2D.hashCode() implementation and "other" could use the DirectPosition.hashCode() contract, thuse violating the condition that this.equals(other) implies this.hashCode() == other.hashCode(). Conclusion: I suggest that in GeoTools implementation, most equals(Object) implementations require the exact same class. I know that some other GeoTools developpers asked for the opposite, but I believe that the opposite can be a cause of subtle bugs. The one described in this email could have been unoticed for long if we didn't had this "assert" statement. We can replace some "same class" requirements by "instanceof" on a case-by-case basis rather than as a general rule. As far as the Point2D / DirectPosition clash is concerned, I had no other choice than writting a javadoc warning about it since we can't change Point2D implementation. Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
