Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[mark.reinhold at oracle.com]

2016/7/13 16:15:33 -0700, peter.levart at gmail.com:
> On 07/13/2016 11:47 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> If the container is set up to provide, e.g., Hibernate to this particular
>> application, then it could narrow the accessibility of the entity classes
>> by rewriting the above module declaration to refine the `exports dynamic`
>> directive:
>> 
>>     module com.foo.data {
>>         requires java.persistence;
>>         exports dynamic com.foo.data.model
>>              to hibernate.core, hibernate.entitymanager;
>>     }
>> 
>> (This is one of the very few use cases for qualified dynamic exports.)
>> 
>> Whether standalone or in a container the same set of packages is exported
>> by the module; the only difference is that, inside the container, the
>> exports are qualified.
> 
> What additional metadata does container need to rewrite a module 
> descriptor like in above example? Does it need the whole set of exports 
> that replace existing dynamic exports? Or only the target modules that 
> it "attaches" to all unqualified dynamic exports? If the later, then 
> what does container do if one wants to rewrite only a selection of 
> unqualified dynamic exports to target one set of modules (for example an 
> IoC implementation) and  another (possibly overlapping) selection of 
> exports to target some other set of modules (for example a JPA 
> implementation)? Does it give up and "attaches" all targets to all 
> unqualified dynamic exports ?
> 
> I think something is missing here. A kind of hook to identify or "tag" a 
> set of unqualified dynamic exports so that it can be located by the 
> container.

I think we can address this with the tools that we already have, along
the lines of what Stephane Epardaud suggests nearby.

The container can already see that the `com.foo.data.model` package
contains elements marked with annotations from the `java.persistence`
module.  If the Hibernate modules are annotated

    @RefineDynamicExports({ javax.persistence.Converter.class,
                            javax.persistence.Entity.class,
                            javax.persistence.Embeddable.class,
                            javax.persistence.MappedSuperClass.class })
    module hibernate.core { ... }

    @RefineDynamicExports({ javax.persistence.Converter.class,
                            javax.persistence.Entity.class,
                            javax.persistence.Embeddable.class,
                            javax.persistence.MappedSuperClass.class })
    module hibernate.entitymanager { ... }

then the container could refine the dynamic export of a package that
contains elements annotated with @Converter, @Entity, etc., from being
unqualified, as it was originally written, to being qualified to these
two Hibernate modules.  (It could refine unqualified dynamic wildcard
exports in the same fashion.)

In a @RefineDynamicExports annotation you wouldn't have to list all the
annotations in the relevant package but just the main ones, any one of
which whose presence implies use of the framework.

- Mark