Paul Bakker paul.bakker.nl at gmail.com
Fri May 12 16:36:41 UTC 2017

Got it! It makes sense after this example. As a bit of feedback: I do think the naming of the properties is confusing. Because they are the same as the --add-opens/--add-exports flags, my assumption was they would work (exactly) the same.
Naming things is hard, and I don't have a better alternative, but maybe a more descriptive name could be considered for the properties? 



> On May 12, 2017, at 12:26 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 11/05/2017 21:25, Paul Bakker wrote:
>> I'm a little confused by "...deployments work if they are dependent on JDK internal APIs". What does internal JDK usage have to do with opening/exporting your own packages? I would think this solves the problem that some other code (e.g. a library) requires access to application code?
>> Also, can you elaborate why this only applies to the unnamed module and can't do the same a the --add-exports/--add-opens flags?
> Hopefully the mail that Mandy references gives the context.
> As an example, suppose an executable JAR that has code that is hacking into sun.awt.X11 for some reason. To keep that code working then you could do:
> java --add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -jar app.jar
> but this isn't convenient for end-users that double click JAR files. The equivalent for an executable JAR is to add "Add-Opens: java.desktop/sun.awt" to its main manifest.
> -Alan

More information about the jigsaw-dev mailing list