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.
###@###.### 2005-05-11 02:48:52 GMT