United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4212732 : javac seems to ignore classpath manifest entries in jar files

Details
Type:
Enhancement
Submit Date:
1999-02-18
Status:
Resolved
Updated Date:
2003-10-24
Project Name:
JDK
Resolved Date:
2003-10-24
Component:
tools
OS:
solaris_8,solaris_2.6,linux,generic,windows_2000
Sub-Component:
javac
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0,1.2.2,1.3.0,1.4.0,1.4.1_03
Fixed Versions:
5.0 (b26)

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.


                                    

Comments
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
                                     
2003-10-02
PUBLIC COMMENTS

javac ignores classpath manifest entries in jar files included in its classpath.
                                     
2004-06-10
SUGGESTED FIX

javac should probably use the same class loading semantics/engine as java does.
                                     
2004-06-11
WORK AROUND

The "brute force" workaround is to explicitly add "all" implicitly referenced jar files into javac's classpath.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger-beta

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-b26
tiger-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together