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. Thanks, Kevin On 7/30/07, Craig L Russell <[EMAIL PROTECTED]> 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 http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > >
