[cp-patches] [PATCH] Fix HashMap.put() to check for hashCode equality before equals()

[Pekka Enberg]

This patch is needed to run Jython 2.5.2 RC 4 under JamVM and GNU Classpath CVS
HEAD. It turns out Jythin bootstrap is bit hairy and assumes HashMap.put()
checks for hashCode equality before invoking Object.equals().

Signed-off-by: Pekka Enberg penb...@kernel.org
---
 ChangeLog  |6 ++
 java/util/HashMap.java |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7eeacf0..05aa794 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,12 @@
 2011-02-22  Pekka Enberg  penb...@kernel.org
 
* java/util/HashMap:
+   (put): Check for key hashCode equality before invoking
+   Object.equals() to fix compatibility issue with Jython.
+
+2011-02-22  Pekka Enberg  penb...@kernel.org
+
+   * java/util/HashMap:
(DEFAULT_CAPACITY): Make default initial capacity 16 as it is
defined in official Javadocs.
 
diff --git a/java/util/HashMap.java b/java/util/HashMap.java
index 108bf25..2f56932 100644
--- a/java/util/HashMap.java
+++ b/java/util/HashMap.java
@@ -345,7 +345,7 @@ public class HashMapK, V extends AbstractMapK, V
 
 while (e != null)
   {
-if (equals(key, e.key))
+if ((key.hashCode() == e.key.hashCode())  equals(key, e.key))
   {
 e.access(); // Must call this for bookkeeping in LinkedHashMap.
 V r = e.value;
-- 
1.7.1

Re: [cp-patches] [PATCH] Fix HashMap.put() to check for hashCode equality before equals()

[Mark Wielaard]

On Tue, 2011-02-22 at 17:02 +0200, Pekka Enberg wrote:
 This patch is needed to run Jython 2.5.2 RC 4 under JamVM and GNU Classpath 
 CVS
 HEAD. It turns out Jythin bootstrap is bit hairy and assumes HashMap.put()
 checks for hashCode equality before invoking Object.equals().
 [...]
  2011-02-22  Pekka Enberg  penb...@kernel.org
  
   * java/util/HashMap:
 + (put): Check for key hashCode equality before invoking
 + Object.equals() to fix compatibility issue with Jython.

That seems a fine optimization in itself. But any application depending
on it is pretty e :{ O well, that is how it is I guess. We had
something similar in the initialization order of eclipse, where they
depended on equals being called in a particular direction. sigh.

Thanks,

Mark