jpackage multiple --add-exports

Andy Herrick andy.herrick at
Mon May 20 23:32:02 UTC 2019

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.


On 5/20/2019 3:36 PM, Craig Bester wrote:
> Hi!
> When using the JDK13-EA jpackage utility (
> 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/,ALL-UNNAMED
> --add-exports=javafx.controls/,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
> The same issue occurs when using the
> older javapackager too. Switching the order of the statements causes
> calls to throw an IllegalAccessError instead.
> Running the jar directly works fine: “java --module-path=.
> --add-exports=java.base/,ALL-UNNAMED
> --add-exports=javafx.controls/,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:

More information about the core-libs-dev mailing list