I've been trying your example (or something I have created that is close
to it) and thought I was seeing multiple --add-exports are passed to the
VM in my case.
But on closer look I think when I have 3 "--java-options
--add-exports=..." jpackager options, I get the three expected lines in
[JavaOptions], but the VM starting the app seems to get the first
--add-exports argument 3 times, instead of the three distinct ones.
This is clearly a bug I will file tomorrow.
It also shows the need for easier debuging of these cases. We should
have some mechanism to see the full set of args passed to the VM.
/Andy
On 5/20/2019 3:36 PM, Craig Bester wrote:
Hi!
When using the JDK13-EA jpackage utility (https://jdk.java.net/jpackage)
specifying multiple ‘--add-exports' arguments with ’--java-options' results
in the executable only passing the first ‘--add-exports' to the JVM.
For example, if the .cfg file generated by jpackage holds the following
arguments:
[JavaOptions]
--module-path=.
--add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
--add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
--add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing
The second ‘--add-exports' will be ignored and an IllegalAccessError will be
thrown when attempting to access anything under
com.sun.javafx.scene.control.skin. The same issue occurs when using the
older javapackager too. Switching the order of the statements causes
sun.security.util calls to throw an IllegalAccessError instead.
Running the jar directly works fine: “java --module-path=.
--add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
--add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
--add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing -jar
AppName.jar”
Is there an alternative method to specify exports when packaging a jar?
Specifying ‘Add-Exports’ in the jar manifest does not work.
--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html
