> From: Alan Bateman <alan.bate...@oracle.com> > To: Andrew Guibert <aguib...@us.ibm.com>, jigsaw-dev <jigsaw- > d...@openjdk.java.net> > Date: 05/18/2017 08:44 AM > Subject: Re: Add-Reads and Add-Modules manifest attributes? > > On 18/05/2017 14:40, Andrew Guibert wrote: > > > > > I was happy to see that a resolution was reached for #AddExportsInManifest, > > but why did this stop at Add-Exports and Add-Opens? In order to cover all > > use cases (for unnamed modules), we would need two more manifest > > attributes: > > > > # Equivalent to: --add-reads=java.base=ALL-UNNAMED > > --add-reads=java.sql=ALL-UNNAMED > > Add-Reads: java.base, java.sql > > > Unnamed modules read all modules so you don't need this.
Regarding Add-Reads: You're reading it backwards I'm afraid =) This example is saying "java.base needs to read ALL-UNNAMED modules" But regardless of what example was given, it is a valid use case right? Regarding Add-Modules: I see that Reto made a similar request last week for --add-modules as a manifest attribute. You mentioned that there is no equivalent to `--add-modules` in executable JARs along with some backing evidence that it needs to be used in conjunction with `--module-path` and such. However, couldn't the JVM make a best effort to read and process an `Add-Modules` attr? I would argue that a vast majority of cases will be adding one of basic values (i.e. java.se.ee or ALL-SYSTEM) which do not need to be used in conjunction with `--module-path`.
