openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
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 14:13:04 GMT
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 <kwsutter@gmail.com> 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 <Craig.Russell@sun.com> 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: Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
>

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