JDK-8227497 : No documented method for setting module addexports to JNI_CreateJavaVM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2019-07-09
  • Updated: 2019-10-28
  • Resolved: 2019-07-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14
11.0.6-oracleFixed 13 b30Fixed 14Fixed
Related Reports
Relates :  
JDK-8227722 - Update JNI Spec w.r.t. VM implementation-specific long form options
Description
A DESCRIPTION OF THE PROBLEM :
The interactions between the new module system and JNI do not appear to be documented.    Though there are many new options available when calling java from the command line, those options are not currently accepted by JNI_CreateJavaVM.  Directly attempting to set properties such as "jdk.module.addexports"  produce

Java HotSpot(TM) 64-Bit Server VM warning: Ignoring system property options whose names match the '-Djdk.module.*'. names that are reserved for internal use.

There needs to be additional documentation of how new language features such as modules interact with JNI.   Without such documentation, it is difficult to access features when embedding the JVM that are available when launching from the command line.
Comments
>> There is no public changeset for this, right? That is correct.
25-07-2019
There is no public changeset for this, right? Putting openjdk-na to get it off 11u backporting radar.
25-07-2019
I tend to agree with Mandy here - the JNI spec should document the format of how to pass options rather than listing any specific options (which rightly belong in the Java launcher manpage as Mandy stated). But we also need to make clear you can only pass VM options this way not launcher options. Unfortunately with JEP-293 the difference between launcher options and VM options is even less clear than in the past.
19-07-2019
True and not that --module-path and other module options are HotSpot VM-specific options. What I suggested was to add an implementation note after "In addition, each VM implementation may support its own ..." to extend to document the long form option syntax and include an example or not. It's not part of the JNI specification. The full list of HotSpot VM supported options should be referred to the java launcher man page rather than listing all these options in JNI specification.
15-07-2019
The JVM does not accept all of the Java --<name>=<value> options. For example, it does not support --module=, --describe-module=, or --class-path=.
15-07-2019
The HotSpot VM will accept options of the long form name use `=` as the separator for any argument value as documented in https://openjdk.java.net/jeps/293. It'd be better to document the format `--<name>=<value>` for options starting with `--` and use --module-path as an example.
15-07-2019
The way to pass options such as --add-exports to JNI_CreateJavaVM() is to use this form of -add-exports: --add-exports=module/package=target-modules instead of: --add-exports module/package=target-modules The '=' immediately after --add-exports is needed so that no blank characters appear in the command. Blank characters confuse JVM argument parsing. Since most of the -add-exports documentation talks only about the "-add-export ..." form, perhaps we should add text to the JNI manual explaining that the --add-export=, -add-reads=, etc. versions of those commands are needed when using JNI_CreateJavaVM().
12-07-2019