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 :  
Description
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.

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

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.
15-12-2005

SUGGESTED FIX Disable 6268383, or redo from scratch.
15-12-2005

EVALUATION Should be addressed before beta.
03-10-2005