Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Peter Levart]

Hi,

I have a question about the following ...

On 07/13/2016 11:47 PM, mark.reinhold at oracle.com wrote:
> To point (2), if some packages in a user module need to be exported for
> reflection at run time, and a container wishes to ensure that only select
> "trusted" framework modules can access the types in those packages, then
> that's already expressible today.  We can also ensure that the set of
> packages exported by a module is the same whether it's used standalone
> on Java SE versus inside a container, which as you observe elsewhere in
> this thread [1] could be problematic.
>
> Suppose, e.g., we have an application module that's written against JPA,
> rather than any specific JPA implementation, and exports the package
> containing its entity classes for reflection at run time:
>
>      module com.foo.data {
>          requires java.persistence;
>          exports dynamic com.foo.data.model;
>      }
>
> When used standalone, outside of a container, this module will export the
> package containing its entity classes for reflection at run time.  The
> classes will be accessible to every other module, but from a security and
> integrity standpoint we assume that whoever invokes the run-time system,
> i.e., whoever provides the command-line arguments to the `java` launcher
> or its equivalent, is trusted to ensure that no adversarial modules are
> present.
>
> When used inside a container, the container already has the power to
> prevent an adversarial module from accessing the module's entity classes.
> That's because we expect containers to load every application into a
> unique layer [2], and a container can rewrite module descriptors when
> configuring a layer.  This is nothing to be ashamed of -- we fully expect
> it to become a common practice.
>
> 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.

Regards, Peter