Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports
David M. Lloyd
david.lloyd at redhat.com
Thu Nov 3 16:08:28 UTC 2016
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 , 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?
> 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.
More information about the jpms-spec-observers