Bug ID: JDK-4212732 javac seems to ignore classpath manifest entries in jar files

Type: Enhancement
Component: tools
Sub-Component: javac
Affected Version: 1.2.0,1.2.2,1.3.0,1.4.0,1.4.1_03

Priority: P4
Status: Resolved
Resolution: Fixed
OS:
generic,linux,solaris_2.6,solaris_8,windows_2000 generic,linux,solaris_2.6,solaris_8,windows_2000
CPU: generic,x86,sparc

Submitted: 1999-02-18
Updated: 2021-12-15
Resolved: 2003-10-24

Other
5.0 b26Fixed

javac doesn't seem to "pull in" other jar files listed in the classpath manifest of any jar files included in javac's explicityly defined classpath.

For example, if B.jar includes A.jar in its classpath manifest and I run:

javac -classpath B.jar

I'll receive "class not found" errors for the classes included in A.jar.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b26 tiger-beta
14-06-2004
WORK AROUND The "brute force" workaround is to explicitly add "all" implicitly referenced jar files into javac's classpath.
11-06-2004
SUGGESTED FIX javac should probably use the same class loading semantics/engine as java does.
11-06-2004
PUBLIC COMMENTS javac ignores classpath manifest entries in jar files included in its classpath.
10-06-2004
EVALUATION It is not clear that the compiler should search for classes in exactly the same way as the VM, for example, it would likely be inappropriate to compile against classes accessed remotely over a network from a third-party server not under control of the developer, for version-control reasons. In general, you want a controlled, reproducible environment for compiling software. It would perhaps simplify the use of libraries distributed as '.jar' files, however, if locally-installed '.jar' files on the manifest classpath were honored. william.maddox@Eng 1999-11-30 Since these entries are always relative, ALL of them are local. neal.gafter@Eng 2001-04-19 It is unclear if the specification for the compiler should be extended to support what is requested here. Currently, these entries are documented only to apply to the VM. ###@###.### 2001-08-22 We have no plans to address this requested feature in the next two releases, so I have closed it as "will not fix". ###@###.### 2001-11-12 This bug did have 41 votes and 4 customer calls before I closed it, and I have received a number of messages, directly and indirectly, from customers who would really like this feature added. I regret closing this bug report. I have reopened it. In my defense I would like to say that this is a feature addition, and therefore cannot be added into a dot dot release (such as 1.4.1 or 1.4.2), and so the next possible release in which this feature could be added is 1.5. The 1.5 release is in planning, but we suspect the requirements for javac will severely stretch the limits of our resources even without including this feature. I had closed the bug under the logic that its a feature that we were unlikely to add in the next 3 releases (1.4.1, 1.4.2, and 1.5). Nevertheless, this feature has enough interest that I believe it is best to reopen it until we can get to it. If you are one of those who had voted for it before, and you are still interested in this feature, by all means please re-cast your votes for this one. I would make that happen automatically if I could. I apologize. ###@###.### 2001-11-29 Its not clear to me why this needs to be deferred to a Minor release (1.5). Solaris adds fully compatable features in update/Micro releases and the official release taxonomy has been modified (several years ago) to reflect this. Besides, the existance of a Java 1.4.1 API specification, unique from the 1.4.0 specification, would seem to indicate that Java is following the same model. Would this change be incompatable in some edge condition? If not, it would seem appropriate to be fixed at any time. (Well, not in a patch release.) I'll note that its been more than a year since there has been activity on this report. ###@###.### 2002-12-16 Yes, it will be incompatible when a jar file earlier on the class path contains a manifest entry that would cause a referenced class to be found instead of finding that class from a later entry on the class path. 1.4.2 is already past feature freeze, so it is not possible to add any features to 1.4.2. The solaris criteria for including features in releases are not the same as the criteria for Java. ###@###.### 2002-12-16 The spec for the classpath manifest entry states "The manifest can define a JAR-class-path, which further extends the class path (but only while loading classes from that JAR)." I suspect this doesn't mean what it literally says. ###@###.### 2003-06-18 When finding a jar file on the user classpath, the classpath entries listed on the Class-Path Manifest entry should be effectively inserted after the jar file on the classpath, and any jar files found there should be expanded recursively. Omitting the addition of duplicate jar files on the classpath is an obvious optimization, but one that is completely necessary to avoid infinite recursion of jar file classpath expansion if jar files recursively reference each other. We don't expand jar file class paths on the bootclasspath or those found in the extensions directory because the VM doesn't do this either. ###@###.### 2003-10-02
02-10-2003

Duplicate :	JDK-4663688 - javac should support JAR dependencies
Duplicate :	JDK-4495283 - Javac ignores the ClassPath attribute in jar file manifests
Relates :	JDK-6934615 - Relative classpaths in jarfile manifests are handled inefficiently by rmic
Relates :	JDK-6999460 - Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux
Relates :	JDK-6473331 - rmic does not use manifest classpath
Relates :	JDK-8278856 - javac documentation does not mention use of Manifest class-path attribute
Relates :	JDK-6485027 - javac incorrectly handles relative paths in manifest classpath