JDK-6206485 : JAR file extension classpath resolver has cyclic dependency problems
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2004-12-09
  • Updated: 2016-03-23
  • Resolved: 2006-05-09
Related Reports
Duplicate :  
JDK-6400872 - REGRESSION: Java Compiler cannot find jar files referenced by other
Description
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).
###@###.### 2004-12-09 16:55:05 GMT
Comments
EVALUATION 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. ###@###.### 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. ###@###.### 2005-03-17 04:04:07 GMT
09-12-2004