JDK-8166438 : New-style module arguments are allowed only using alternate form in webstart where both forms are allowed from command line
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2016-09-12
  • Updated: 2017-06-14
  • Resolved: 2016-09-28
Related Reports
Duplicate :  
Relates :  
Relates :  
Sub Tasks
JDK-8182483 :  
Description
FULL PRODUCT VERSION :
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+135)
Java HotSpot(TM) Server VM (build 9-ea+135, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
According to JEP-261 http://openjdk.java.net/jeps/261 arguments related to tweaking of the module system can be specified as
--add-exports <source-module>/<package>=<target-module>(,<target-module>)*
or
--add-modules <module>(,<module>)*

These options work when launching a Java application from the command line.

However, when launching from a Web Start file I seem to have to specify as
--add-exports=<source-module>/<package>=<target-module>(,<target-module>)*
or
--add-modules=<module>(,<module>)*

(Note the extra '=' character)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Deploy a web start application necessitating extra module startup options (example attached). (Our application is deployed as a signed JAR file with a DRS 'run' rule but I don't think this makes any difference to this bug)
2. Launch it

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should fail to launch when module options are not specified
The application should launch correctly when module options are correctly specified
ACTUAL -
The application failx to launch when module options are not specified (good)
The application does not launch correctly, even if module options are correctly specified (bad)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
test.jnlp
=========

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="6.0+" codebase="http://www.example.com/webstart" href="test.jnlp">
<information>
      <title>Test app</title>
      <vendor>Anon</vendor>
      <offline-allowed/>
    </information>
    <security>
        <all-permissions/>
    </security>
    <update check="always" policy="always" />
    <resources>
      <j2se version="1.8+" java-vm-args="--add-exports java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-modules java.se.ee"/>
      <jar href="test.jar" main="true"/>
    </resources>

    <application-desc main-class="Toto"/>
  </jnlp>

Toto.java
=========

import com.sun.java.swing.plaf.windows.WindowsLookAndFeel;
import javax.swing.UIManager;
import javax.xml.bind.JAXBException;
import java.text.*;
import java.util.*;

public class Toto {
  public static void main(String... argv) throws Exception {
        if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) System.out.println("Using Windows L&F");
        new JAXBException("Testing").printStackTrace();
  }
}

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

CUSTOMER SUBMITTED WORKAROUND :
Specify module options incorrectly as
 java-vm-args="--add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-modules=java.se.ee"

I haven't tested other module options (limit-modules, add-reads, etc., etc.) but of course all options specified in JEP-261 which are allowed for Web Start applications should be handled correctly.


Comments
The deployment team agreed this should not be fixed. for JDK9, only "--add-modules=" will be a secure vm arg prefix, not also "--add-modules ". Same goes for the semi-secure vm arg prefix "--add-exports=", not also "--add-exports " There are certain security concerns to allowing a secure vm arg prefix to end in space character, and since the other form is supported, there is no loss of functionality in allowing only that one.
28-09-2016

This can be confirmed with the dialog test example at: http://oklahoma.us.oracle.com/www/tests/dialogs/jnlp/ awt9.jnlp uses <java version="9*" java-vm-args="--add-exports jdk.javaws/com.sun.jnlp=ALL-UNNAMED .../> awt9-space.jnlp uses: <java version="9*" java-vm-args="--add-exports jdk.javaws/com.sun.jnlp=ALL-UNNAMED .../> We could fix this in JREDesc constructor, simply by converting "--add-modules XXX" and "--add-exports YYY" in the vmargs attribute to the other form ( "--add-modules=XXX" and "--add-exports=YYY" ) . Since these are the only two such args ever considered secure. if (vmargs != null) { vmargs = vmargs.replaceAll("--add-modules ", "--add-modules=").replaceAll("--add-exports ", "--add-exports="); } we could also do nothing , and close this as not a bug, by stating that the semi-secure vm-arg prefix is only "--add-exports=", and the deployment code will not consider the other form to be secure.
26-09-2016

the java usage output "java -help" states that both usages are acceptable: "To specify an argument for a long option, you can use --<name>=<value> or --<name> <value>." The form without a space in it seems to be working fine. The form with a space in it seems to be in contradiction to assumptions of the code parsing the java-vm-args attribute which assumes that the value of the attribute is a list of vm arguments delimited by spaces. As a result "--add-exports" is taken as one arg, and "java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED" is taken as another arg. Neither of these are listed as secure args or secure vm-arg prefixes so they are not used when coming from unsigned jnlp file. (the semi-secure vm-arg prefix is "--add-exports="). in previous versions there were no vm-args defined to have spaces in them, except within the values which would have to be quoted.
26-09-2016

Checked this for 9 ea b136 and could confirm the behaviour as reported (run attached test case).
21-09-2016