openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: svn commit: r557089 - in /openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/ openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/kernel/ openjpa-lib/src/main/ja
Date Mon, 30 Jul 2007 12:45:20 GMT
Craig, Marc, and Patrick,
You guys work too late on a Sunday night...  :-)  Thanks for the input.

I haven't found all of the details on the problem report that made this
change, but the abstract indicates "hashmap performance changes".  So, our
findings would be consistent with that.

I just wanted to see if anybody thought that this behavior of the
HashMap.put() was inconsistent with the java spec or if there was some
strong opinion on the use of == for this situation.

I'll make the equality changes and work through the other issues with the
testcase failing.


On 7/30/07, Craig L Russell <> wrote:
> It would not surprise me that IBM JDK was internally "interning"
> Integer instances much like String instances are interned, to reduce
> the number of instances of Integer and thereby improve garbage
> collection and instance count.
> But our code should not be using == instead of equals. The identity
> of an Integer should never be assumed. Best practice even if not
> mandated by the VM spec.
> Craig
> On Jul 29, 2007, at 10:35 PM, Marc Prud'hommeaux wrote:
> >> The problem is that the IBM JDK seems to want to create (copy) new
> >> Integer
> >> objects when used as keys to the HashMap.put(k,v) method.  Any
> >> other key
> >> types are just used as is (no copy).  But, Integer types as keys
> >> are copied
> >> into new Integer objects.
> >>
> Craig Russell
> Architect, Sun Java Enterprise System
> 408 276-5638
> P.S. A good JDO? O, Gasp!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message