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.
Since these entries are always relative, ALL of them are local.
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.
We have no plans to address this requested feature in the next two releases,
so I have closed it as "will not fix".
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.
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.
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
The solaris criteria for including features in releases are not the same as
the criteria for Java.
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.
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.