16

I observe a strange behavior of wildcard expansion behavior for Java7 on Windows.

For centuries there was a clean difference between "*" versus *.
Seems this it not longer true for Java7 (at least on Windows7).

I noticed the problem when using a wildcard classpath.
In despite of quoting the wildcard-classpath it gets expanded.
Thus it seems not possible any more to pass a wildcard to the java application.

So using java -cp "somewhere/*" will fail (as does "somewhere\*").

A workaround seems to be: java -cp "somewhere/*;" which inhibits the expansion.

To verify the behavior I wrote a small Echo.java class.

I found that using java 1.6.0 quoted "*" and plain * works like expected, whereas on Java7 I always got the expanded wildcard. Until now this was observed on Windows7, don't know what happens on XP.

The problem arises, since wildcards on Windows are never ever expanded by dark age CMD.EXE (like any shell does on UNIX). Instead each executable has to perform this explicitly using setargv.obj.

I found two related issues which seem to describe a similar problem:

Is this observed by someone else?
Or are there some obscure Windows or batch-file settings to control this?

Dieter.

Ditz
  • 707
  • 7
  • 15
  • 1
    If you set environment variable `_JAVA_LAUNCHER_DEBUG` launcher will show additional info about expanding classpath. Maybe it will help to understand what is going on inside java.exe. – Mersenne Feb 08 '12 at 15:03
  • this one is related http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7020954 – Oleg Mikheev Feb 08 '12 at 18:40
  • using `_JAVA_LAUNCHER_DEBUG` also shows that `"*"` decays: java -cp . Echo "*" Command line args: argv[0] = C:\Program Files\Java\jdk1.7\bin\java.exe argv[1] = -cp argv[2] = . argv[3] = Echo argv[4] = Echo.class argv[5] = Echo.java – Ditz Feb 08 '12 at 19:16
  • thank you, @Ditz - this saved my day! i am using Maven's exec plugin and needed to pass a wildcard classpath to the JVM (without shell globbing). path/to/jars/*; did the trick! – RubyTuesdayDONO May 07 '12 at 19:16
  • … but one caveat - this could break if any file names in the path contain a semicolon (unlikely but possible). – RubyTuesdayDONO May 07 '12 at 19:52
  • Adding a semicolon after the wildcard didn't work for me so I ended up listing all the jars files and it works this way. Cursed be Java7! – Guillaume Mar 10 '15 at 15:33

2 Answers2

7

Yes, I noticed the same issue.

  • It's explained as a 'known issue' in the release notes for Java7 update 4.

  • Here is the bug report. The fix will be delivered in Java7 update 8 (current release is update 6).

  • Note that there isn't a shell-options workaround, because in Windows, the shell doesn't handle wildcard expansion. (Whereas in Unixes, the shell performs the expansion).

laher
  • 8,102
  • 3
  • 27
  • 37
0

Not a direct solution to the broken /* issue but I hope you could use the following script to ease your situation.

 libDir2Scan4jars="../test";cp=""; for j in `ls ${libDir2Scan4jars}/*.jar`; do if [ "$j" != "" ]; then cp=$cp:$j; fi; done; echo $cp| cut -c2-${#cp} > .tmpCP.tmp; export tmpCLASSPATH=`cat .tmpCP.tmp`; if [ "$tmpCLASSPATH" != "" ]; then echo .; echo "classpath set, you can now use  ~>         java -cp \$tmpCLASSPATH"; echo .; else echo .; echo "Error please check libDir2Scan4jars path"; echo .; fi;

Scripted for Linux, could have a similar one for windows too. If proper directory is provided as input to the "libDir2Scan4jars"; the script will scan all the jars and create a classpath string and export it to a env variable "tmpCLASSPATH".

Sreesankar
  • 301
  • 2
  • 6