Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Gunnar Morling]

Hi,

Putting my user's hat on, I'm interested in a solution which a) fulfils my
desire to hide types internal to my implementation as much as possible
(that's why I'm using a module system after all) and b) still is easy to
use.

Looking at the proposal, I feel adding *un-qualified* dynamic exports goes
against a) - every other module can access my internal types reflectively.
b) is only partly addressed, too - I need to list all my internal packages
(there may be many of them).

Adding *qualified* dynamic exports addresses a) (only selected modules may
access my internal types), but makes things worse for b) as I now need to
list all my internal packages *and* the modules meant to access them.
Tooling for generating the exports may help, but I feel that's dealing with
symptoms rather than addressing the cause (1).

Making internal types available to reflection by default as suggested
before in this thread does address a) not at all, but b) very much.

Personally, I find none of these solutions very compelling.

A solution that'd address a) and b) would be a way for allowing me as a
user to whitelist "trust-worthy modules" in one single spot.

I.e. a global descriptor of sorts where I can say "export foo.internal.* to
hibernate". I know Hibernate needs to use reflection, I'm ok with it doing
this, but I want to express that fact only once in a single place, and
using something like wildcards, for the sake of b). As the export is
qualified, and if needed also could be given on a more fine-grained level,
a) is addressed, too.

Such descriptor should live on the application (not module) level for the
sake of b) but also in order to allow for alignments with the specific
runtime environment. E.g. a third party module might have been compiled
with EclipseLink, while in my application I might want to use it with
Hibernate.

In container environments (Java EE), the container may create that
descriptor to address all the requirements of all the modules a specific
deployment is using to further simplify the user's life.

I think such approach would help with exposing internal types as less as
possible while still keeping things manageable for the user.

--Gunnar

(1) Btw. qualified exports with several targets (export foo to a, b) may be
tough to deal with when it comes to different tools involved. E.g. two
annotation processors, each aware of one such target requiring the export.
If that could be given in two distinct export statements, that'd help as
each tool than simply can add its entry rather than potentially updating an
existing one.



2016-07-08 11:16 GMT+02:00 Alan Bateman <Alan.Bateman at oracle.com>:

>
>
> On 08/07/2016 09:39, Sander Mak wrote:
>
>> That is, define your module-info's, possibly containing dynamic exports
>> if your framework of choice does its magic through reflection.
>>
>> Right and there is nothing in this proposal that is specific to core
> reflection either. The framework that I am using might be spinning bytecode
> or maybe it switches to using method handles when there is a waning gibbous
> moon - that's implementation detail that the user of the framework should
> be oblivious too.
>
> -Alan
>