FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux starpc8.phyast.dur.ac.uk 2.4.20-37.9.legacy #1 Mon Sep 27 19:40:23 EDT 2004 i686 athlon i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
When compiling against a set of jar files that have a certain type of cyclic dependency
the compiler can use excessive resources and sometimes fail to compile.

This only seems to apply when the classpaths have relative paths, i.e. paths like .../a/a.jar
.../b/b.jar. Under these conditions the compiler reports that the search path for the source files is
a/a.jar, a/../b/b.jar, a/../b/../a/a.jar, a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/a.jar and so on, rather than
just the two files shown (and may exhaust some resource and abort or hit some other limit and compile successfully).

There is probably a need to use canonical file names when determining equality between jar files on the extension classpath.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create two jar files "a.jar" and "b.jar" in subdirectories "a" and "b". Set the extension classpaths
to refer to each other using relative paths (i.e. for a/a.jar set it to .../b/b.jar and for b/b.jar to ../a/a.jar)
now compile some dependent class against these:

  javac -verbose -cp a/a.jar DependentClass.java


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
[parsing started DependentClass.java]
[parsing completed 45ms]
[search path for source files: [a/a.jar, b/b.jar]]

ACTUAL -
[parsing started DependentClass.java]
[parsing completed 43ms]
[search path for source files: [a/a.jar, a/../b/b.jar, a/../b/../a/a.jar, a/../b
/../a/../b/b.jar, a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a/../b/b.jar,
 a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a/../b/../a/../b/b.j
ar, a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a/../b/
../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a
.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/b.jar, a/../b/../
a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a
/../b/../a/../b/../a/../b/../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/
../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a/../b/.
./a/../b/../a/../b/../a/../b/../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/..
/b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../
b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/b.jar, a
/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a
/../b/../a/a.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/
../b/../a/../b/../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/../a/../b/.
./a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/..
/a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/..
/a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../
b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/../b/../a/../b
/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b
/../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/
../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/a.jar, a/.
./b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/.
./b/../a/../b/../a/../b/../a/../b/../a/../b/b.jar, a/../b/../a/../b/../a/../b/..
/a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../a/../b/..
/a/../b/../a/../b/../a/a.jar, a/../b/../a/../b/../a/../b/../a/../b/../a/../b/../

and so on.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Don't have cyclic dependencies in jar classpaths (but for a complex system, we have 120 jar files, spread through package dependent directories, that can be a lot of trouble).
  xxxxx@xxxxx   2004-12-09 16:55:05 GMT

N/A

As the submitter suggests: don't have cycles in jar dependencies.

I don't think this is a real problem as the compiler is presented with an
incorrect environment.  In general, the canonical path is not a reliable
operation so using canonical paths will only solve part of the "problem".

Furthermore, if the compiler were to detect a cycle, it should probably
abort.  This will not solve the submitter's problem.

So I interpret this report as an request for the following:
"please enhance the compiler to diagnose cyclic dependencies in jar files".

In particular, this means that I will change this to a "request for enhancement"
and lower the priority to 5.
  xxxxx@xxxxx   2004-12-09 18:39:37 GMT

In response to SDN feedback, I'm making this a bug again and
resetting the priority to indicate that this would be nice to
fix in Mustang.

  xxxxx@xxxxx   2005-03-17 04:04:07 GMT

If the intention of introducing the resolution of jar file classpaths into
the compiler was to remove the confusion of it not matching those
of the JVM itself, then clearly this is  a misfeature and therefore a bug,
not a request for enhancement.  See 4212732.