I have found several places in DepthFirstAnalysis, Graph, Edge, and the testcase that was using the wrong equality check. The testcase is working much better, but still not perfect.
I need some graphing expertise... In the setup for graph 2 in the testcase, there is a node that has an edge to itself (Node 3 with Integer 3 has an edge to itself). The question is whether this type of edge should be classified as a Back edge or a Forward edge. The testcase seems to expect this type of edge to be a Forward edge, but the analysis of the graph is determining this is a Back edge. I'm not a graphing expert, what's the expected type of edge in this case? Thanks, Kevin On 7/30/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > 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! > > > > > > >
