FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0b64)
Java HotSpot(TM) Client VM (build 1.5.0b64, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Linux starpc8.phyast.dur.ac.uk 2.4.2037.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).
###@###.### 20041209 16:55:05 GMT
