Users of the command line interface to the JVM (such as the "java" command)
on Windows potentially face THREE levels of wildcard expansion:
- expansion performed by their shell (for example if they are using MKS ksh)
- expansion performed by the setargv.obj that is linked into the executables
by our build process
See 4342394: Compilation of Multiple java files failed - added 'setargv.obj' into .exe link step
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_11.asp
- expansion performed by the classpath wildcard feature
See 6268383: Class-path wildcards, jplan feature 082
The classpath wildcard feature, which has always had the potential to cause user
confusion, should be reconsidered in view of this recently discovered additional
source of user confusion, which was a surprise even to the implementor of 6268383.
on Windows potentially face THREE levels of wildcard expansion:
- expansion performed by their shell (for example if they are using MKS ksh)
- expansion performed by the setargv.obj that is linked into the executables
by our build process
See 4342394: Compilation of Multiple java files failed - added 'setargv.obj' into .exe link step
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_11.asp
- expansion performed by the classpath wildcard feature
See 6268383: Class-path wildcards, jplan feature 082
The classpath wildcard feature, which has always had the potential to cause user
confusion, should be reconsidered in view of this recently discovered additional
source of user confusion, which was a surprise even to the implementor of 6268383.
- relates to
-
JDK-4342394 Compilation of Multiple java files filed
- Resolved
-
JDK-7146424 Wildcard expansion for single entry classpath
- Closed
-
JDK-4672990 Command line argument outcome is strange when passed asterisk(*)
- Closed
-
JDK-6268383 Class-path wildcards, jplan feature 082
- Closed
-
JDK-5036373 Tool doc for 'java' should document Windows-specific command arg processing
- Closed