Add-Reads and Add-Modules manifest attributes?

Andrew Guibert aguibert at
Thu May 18 14:14:10 UTC 2017

> From: Alan Bateman <Alan.Bateman at>
> To: Andrew Guibert <aguibert at>, jigsaw-dev <jigsaw-
> dev at>
> 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
> > but why did this stop at Add-Exports and Add-Opens?  In order to cover
> > 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. or ALL-SYSTEM) which do not need to be used
in conjunction with `--module-path`.

More information about the jigsaw-dev mailing list