The DFA result is dependent on the order of the nodes in Graph._nodes.
If the first node visited is 2, then the result is as the Sun jdk
returns it, if the first node visited is 5, you'll get your results.
Maybe changing Graph._nodes from HashMap to TreeMap would give us a
consistent graph set-ups across VMs. Then, we'd need to to re-number
the nodes, so that current node 2 is returned first by the iterator.

My intention for the graph 2 was that I liked to have a cycle detected
by a forward edge. Edge 1->4 will be a forward edge in most
configurations (unless the analysis starts at node 1), but doesn't
indicate a cycle.

Sorry that this test case costs you such a headache. If cycles are
detected as Back- or Forward edges will always depend on the order of
Graph._nodes.iterator(), see DepthFirstAnalysis, line 70.

Thanks,

-- markus.

Kevin Sutter wrote:

Markus,
Thanks for the patch, but I don't need that. I already have the coding
changes done. I'm just trying to figure out how this graphing is supposed
to work. I figured I wanted to get the current testcase to work with the
IBM JDK before making any other changes. If the testcase works with the Sun
JDK, let's get the basic test working with the IBM JDK first. Then, we can
clean up the testcase as your patch below outlines.
You had another reply to this string of notes, but you had changed the
subject line so it didn't get threaded correctly. So, I am including a
portion of that note here to keep the string of notes together:

Single node loops are considered Back edges (Back edges can't occur
during OpenJPA dependency management). For graph 2, the DFA should find:
2 Back edges: (3,3) and (3,2)
2 Forward edges: (2,4) and (1,4) [the edge (1,4) doesn't indicate a cycle]
This results is dependent on the first node chosen for the DFA analysis.
This must must be node 2 for the above result. The starting point is
determined by the order of the nodes in Graph._nodes.

This is not consistent with my findings. Given the setup for graph 2 as it
is currently coded, the analysis begins with node key of 5. From there, the
graph is traversed and my debugging of the edges indicates the following
(the numbers indicate the key):
TREE: 5->4, 4->3, 3->2
BACK: 3->3, 2->4, 2->5
FWD: 1->4
So, I'm confused. If the current testcase works with the Sun JDK, why am I
getting different results just because I changed the equality checks for the
IBM JDK? I also just tried changing the testcase per your patch for the
node and edge definitions and I still get the same result. So, we're not on
the same page somewhere.
Any more ideas? Thanks!
Kevin
On 7/30/07, Markus Fuchs <Markus.Fuchs@sun.com> wrote: