Add-Reads and Add-Modules manifest attributes?

[Andrew Guibert]

> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Andrew Guibert <aguibert at us.ibm.com>
> Cc: jigsaw-dev <jigsaw-dev at openjdk.java.net>
> 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 `java.se.ee` specific modules it
is a must for compatibility.