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?
Thanks, Paul > On May 12, 2017, at 12:26 AM, Alan Bateman <alan.bate...@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
