Opened 15 years ago

Closed 14 years ago

#193 closed defect (wontfix)

PGgeometry.hashCode() does not satisfy certain requirements that are standard in Java

Reported by: danpodeanu Owned by: pramsey
Priority: medium Milestone: PostGIS 1.4.2
Component: postgis Version: 1.3.X
Keywords: Cc:

Description

The org.postgis.PGgeometry class from the PostGIS JDBC extension violates certain standard requirements of Java: for any two Java objects o1 and o2, it should be the case that o1.equals(o2) implies o1.hashCode()==o2.hashCode(). Thus, the following code should print 'true' and 'true'; however, it prints 'true' and 'false' with the 1.3.6 version of the PostGIS JDBC extension:

PGgeometry g1=new PGgeometry("SRID=4326;POINT(2.15426 41.4033)");
PGgeometry g2=new PGgeometry("SRID=4326;POINT(2.15426 41.4033)");
System.out.println(g1.equals(g2));
System.out.println(g1.hashCode()==g2.hashCode());

The error can be demonstrated with the 1.3.6 version of the PostGIS JDBC extension (I am using the postgis_1.3.6.jar file from the official distribution of PostGIS 1.3.6). I have also tried using an SVN version of the 1.4.0 version of the extension and the error persists.

The effect of this error is that PGgeometry objects do not work with Java collections as expected. For example, if g1 from the above example is added to a Java hash-set, the set does not necessarily contain g2, and this is counterintuive since g1 and g2 are equal. In this sense, PGgeometry behaves differently from, say, java.lang.Integer, and this is counterintuitive as well because both classes simply wrap a datatype.

Attachments (1)

hashcode.patch (407 bytes ) - added by pramsey 14 years ago.
Attempt at patch

Download all attachments as: .zip

Change History (6)

comment:1 by pramsey, 15 years ago

Milestone: postgis 1.4.1

by pramsey, 14 years ago

Attachment: hashcode.patch added

Attempt at patch

comment:2 by pramsey, 14 years ago

I have little way to test, does the attached patch help? I'll accept patches… note that the hashCode() implementation in Geometry is commented as "Buggy!" so since this patch depends on it, it might not help.

comment:3 by pramsey, 14 years ago

Milestone: postgis 1.4.1postgis 1.4.2

Moving forward, absent feedback on patch or fix from Java people.

comment:4 by pramsey, 14 years ago

Possibly helpful information from Martin Davis on the JTS list:

 /**
 * Gets a hashcode for this object.
 *
 * @return a hashcode for this object
 */
 public int hashCode() {
  long bits0 = java.lang.Double.doubleToLongBits(p0.x);
  bits0 ^= java.lang.Double.doubleToLongBits(p0.y) * 31;
  int hash0 = (((int) bits0) ^ ((int) (bits0  >> 32)));
    long bits1 = java.lang.Double.doubleToLongBits(p1.x);
  bits1 ^= java.lang.Double.doubleToLongBits(p1.y) * 31;
  int hash1 = (((int) bits1) ^ ((int) (bits1  >> 32)));

  // XOR is supposed to be a good way to combine hashcodes
  return hash0 ^ hash1;
 }

comment:5 by pramsey, 14 years ago

Resolution: wontfix
Status: newclosed

No answers from anyone Java'ish, closing for now.

Note: See TracTickets for help on using tickets.