Add-Reads and Add-Modules manifest attributes?

Andrew Guibert aguibert at
Thu May 18 15:47:20 UTC 2017

> From: Alan Bateman <Alan.Bateman at>
> To: Andrew Guibert <aguibert at>
> Cc: jigsaw-dev <jigsaw-dev at>
> Date: 05/18/2017 09:27 AM
> Subject: Re: Add-Reads and Add-Modules manifest attributes?
> On 18/05/2017 15:14, Andrew Guibert wrote:
> 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?
> I assumed you had transposed them in your mail :-)
> In any case, it's not clear that you need this, at least not for the
> platform modules. Core reflection assumes readability so there
> shouldn't be any issues with code in either module reflecting into
> code on the class path. Maybe you are spinning bytecode? If so then
> you have a visibility issue as the types on the class path are not
> visible to boot or platform loaders. At a stretch then maybe are
> spinning bytecode that uses method handles, that's the only scenario
> that I can think of where you might need to add a read edge at
> runtime, in which case you can just call the reflective APIs. So
> maybe you could help by giving a specific example where you need this.

A concrete use case for an `Add-Reads` manifest attr is beside the point.
Since we have the command line option, why can't we have the equivalent
functionality as a manifest attribute (especially since it seems trivial to
implement)? As long as use cases exist for `--add-reads`, use cases will
exist for the manifest attribute.  If no use cases exist for the
`--add-reads` command line option, can it be removed entirely?

Also, I don't want to forget about the discussion for `Add-Modules`.  I
understand that it may pose a significant technical challenge, but for code
launched via `java -jar` which depends on `` specific modules it
is a must for compatibility.

More information about the jigsaw-dev mailing list