United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6206485 : JAR file extension classpath resolver has cyclic dependency problems

Details
Type:
Bug
Submit Date:
2004-12-09
Status:
Closed
Updated Date:
2016-03-23
Project Name:
JDK
Resolved Date:
2006-05-09
Component:
tools
OS:
linux
Sub-Component:
javac
CPU:
x86
Priority:
P4
Resolution:
Duplicate
Affected Versions:
5.0
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

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
                                     
2004-12-09



Hardware and Software, Engineered to Work Together