Implement jplan feature 082; See http://jplan/feature/082;

The architecture team's decision was:

Class-Path Wildcards 

The context for this discussion can be found in the description of Mustang feature #082. The following recommendations were made.

The syntax for wildcards will be a single asterisk. The class path foo/*, e.g., will load all jar files in the directory named foo. The major advantage of this choice is that it's already familiar to users of the Ant build tool and the various IDEs (e.g., NetBeans) that use Ant. This choice will require careful quotation when used in shell scripts, but it was generally thought that any developer clever enough to use class-path wildcards would also be clever enough to figure out shell quotation.

Only files whose names end in .jar or .JAR will be matched. Files whose names end in .zip, or which have a particular magic number, regardless of filename extension, will not be matched. This is slightly inconsistent with the semantics of the extensions (lib/ext) class path, which for obscure historical reasons also considers zip files, but that was generally considered by those present to be a bug not worth repeating.

Files will be considered regardless of whether or not they are "hidden" in the UNIX sense, i.e., have names beginning with '.'.

A wildcard will only match jar files, not class files in the same directory. If you want to load both class files and jar files from a single directory foo then you can say foo:foo/*, or foo/*:foo if you want the jar files to take precedence.

Subdirectories will not be searched recursively, i.e., foo/* only looks for jar files in foo, not in foo/bar, foo/baz, etc.

Expansion of wildcards will be done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself. This simplifies both the semantics and the implementation and is also the most compatible approach. Each element of the input class path containing a wildcard is replaced by the (possibly empty) sequence of elements generated by enumerating the jar files in the named directory. If the directory foo contains a.jar, b.jar, and c.jar, e.g., then the class path foo/* is expanded into foo/a.jar:foo/b.jar:foo/c.jar, and that string would be the value of the system property java.class.path.

The order in which the jar files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine. A well-constructed application should not depend upon any particular order. If a specific order is required then the jar files can be enumerated explicitly in the class path.

The CLASSPATH environment variable will not be treated any differently from the -classpath (equiv. -cp) command-line option, i.e.,, wildcards will be honored in all these cases.

Class-path wildcards will not be honored in the Class-Path jar-manifest header. The details of this could be worked out, but they'd be nontrivial and there does not appear to be a pressing need for it.

Class-path wildcards should be honored not only by the Java launcher but also by most other command-line tools that accept class paths, and in particular by javac.

Class-path wildcards should not be honored in any other kind of path, and especially not in the bootstrap class path, which is a mere artifact of our implementation and not something that developers should use.

It may be adequate for Mustang for class-path wildcards to be expanded in the Java launcher code. That would support the use of wildcards on the command line and in the CLASSPATH environment variable. It would not, however, support the use of wildcards by applications that embed the JVM; that seems to require expanding wildcards inside HotSpot. Which approach should be taken in Mustang was left as an open issue.
  xxxxx@xxxxx   2005-05-11  customer :48:52 GMT

N/A

Approved by the JAT.
  xxxxx@xxxxx   2005-05-11 02:50:45 GMT

You say that

"Class-path wildcards will not be honored in the Class-Path jar-manifest header....there does not appear to be a pressing need for it."

I disagree, I think there is a need for it. For a start it would be useful, it would save typing and avoid mistakes.
also I have just run into 2 problems 
1) If all the jar s are on the same line I get an IOException: line too long
and
2) if the lines are split with multiple Class-Path: options, as the jar specification says that they can be,  it only includes the last Class-Path: option!!!!

Anything that makes the classpath easier to use should be applauded.  Way to go.

I agree: especially in manifest files, a wildcard would be extremely helpful. If a JAR is added, I not only need to add it to the manifest but also first need to unpack the jar, edit the manifest file, repack it again and deploy it.

OMG!!!  FINALLY!!!!

I can't believe this was finally fixed.  What's really disturbing, is that I only found out about it 3 years later!

You see, I have submitted a bug report requesting class path wildcards THREE times... starting in **1998**!!!  That's TEN YEARS ago!  (see ID's 4143081, 4339262, and 4430150).  All three were marked "Closed, Will Not Fix", with some completely bogus excuse.

The last two of those have been on my Watch List for years.  I figured, if Sun ever got around to fixing this critical problem, I'd get notified.

Well... . no.  That didn't happen.  NONE of those bugs are even in the Related Bugs section.

So... while I heartily applaud Sun for FINALLY doing this, apparently the Bug Database Watch List is a completely useless tool. :-(

I concur that wildcards in the jar-manifest header should be honored.  I am developing a tiered architecture that extensively uses plugins and have a need to look in directories for libraries at the application class loader level.  Although I probably could scan a predetermined directory for libraries, it would certainly be less invasive to be able to specify a directory in the manifest.  Thank you for the consideration.

I think wildcards in the jar-manifest would be very useful. They simplify a lot the manifest itself and any changes to the application libraries.