JDK-6328875 : Multiple command line wildcard expansion confuses Windows users
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-26
  • Updated: 2010-05-08
  • Resolved: 2006-02-17
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
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
- 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.

EVALUATION The engineering team chose to keep the current design/implementation, despite the confusion that will be experienced by some users.

WORK AROUND Instead of java -cp foo/* simply make sure there's a "no-op" classpath component provided, e.g. java -cp foo/*;NOSUCH_FILE_OR_DIRECTORY Making this completely reliable is non-trivial. java -cp foo/*;foo/* works, but will likely cause runtime slowdown, as some jar files will be searched repeatedly.

SUGGESTED FIX Disable 6268383, or redo from scratch.

EVALUATION Should be addressed before beta.