> From: Alan Bateman <alan.bate...@oracle.com> > To: Andrew Guibert <aguib...@us.ibm.com> > Cc: jigsaw-dev <jigsaw-dev@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.
