Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

[David M. Lloyd]

One question and one comment...

On 10/27/2016 06:15 PM, mark.reinhold at oracle.com wrote:
> The open-modules/packages proposal does not support your "Public Only /
> Not Exported" mode, which corresponds to the missing "N S" row in the
> compact table in [2], i.e., the "partly-encapsulated framework client"
> case.  Most reflective frameworks in use today will just reach in via
> `setAccessible` whenever they need to, so whether the members of an
> unexported package in a client module are public or private doesn't
> really matter.  The new proposal intentionally does not support this
> case, which results in a simpler design.

Isn't this essentially the same as doing a module.addReads(otherModule) 
though?  IOW doesn't that essentially say that I can do public-only 
reflection on otherModule, even if it wasn't exported to me, or am I 
misunderstanding read edges (again)?

>>> To confirm my understanding, would it be correct to say that your main
>>> concern here is scenarios in which some of the classes in a user module
>>> are intended to be manipulated reflectively by some trusted framework
>>> module, but that framework module is either not known at compile time or
>>> is otherwise inconvenient to name in the declaration of the user module?
>>
>> Correct.
>
> Good.  I'll enter this as a new issue:
>
>   #IndirectQualifiedReflectiveAccess --- Provide a means by which a
>   client module can grant qualified reflective access to a framework
>   module that is not known at compile time, assuming that the name of
>   some other module that represents the framework module is known.
>   A canonical example of this case is a client POJO module compiled
>   against a module that defines the JPA API.  At run time the client
>   module, or a container or some other code acting on its behalf,
>   must grant qualified reflective access to its POJO packages to the
>   JPA implementation in actual use.

Great.  Also I just want to note that at this point we consider the 
proposal for #ClassLoaderNames to be acceptable, and that I'm still 
working on our reply to the new open modules proposal.

-- 
- DML