FULL PRODUCT VERSION :
$  java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Windows 10

EXTRA RELEVANT SYSTEM CONFIGURATION :
java command line programs launched from cygwin bash and other bourne-like shells.

A DESCRIPTION OF THE PROBLEM :
This is a very subtle issue, and there does not seem to be any workaround possible.  See these links for detailed description of the problem:

http://stackoverflow.com/questions/25948706
http://stackoverflow.com/questions/37037375

The essence of the problem: whether a command line argument with double-quoted wildcards is expanded BY THE JVM depends on which shell the jvm was launched from.  It's difficult to believe that's the intended behavior.

It's as-if some code within the launcher says:

       if ( arg == "*"  && user-shell != "CMD.EXE" ){
            // expand wildcard
       }



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a java program that dumps command line arguments to stdout.
2. call program from cygwin bash shell with quoted asterisk: ( java -cp Dumper "*" )
3. issue same command line from CMD.EXE
4. call a C program that dumps command line arguments, passing a quoted asterisk


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
All 4 steps should produce that same result, the printing of a single asterisk.
ACTUAL -

Steps 2 and 3 produce different results.   Step 2 expands asterisk, Step 3 doesn't.
Step 4 proves that the differing results are caused by the JVM, not the shell environment.



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Dumper {
  public static void main(String[] args){
    for( String arg : args ){
      System.out.printf("[%s]\n",arg);
    }
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :

It should be obvious that there can't be a workaround that allows wildcards to be passed as command line arguments in both environments, the fix has to occur within the JVM.  The end result is that it is impossible to pass an asterisk as a command line argument unless launched from CMD.EXE, a bizarre requirement.