delegating module access

[David M. Lloyd]

Sanne, weak modules already allow this, but the weak module mechanism is 
not adequate, as has been discussed internally.

The question of whether restricting reflection is useful or not is a 
separate discussion.  Our position is that it is a solution for a 
problem that can be solved in other ways, perhaps more effectively, but 
that is left aside for the purposes of the discussion around the 
#ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation issues.

If you accept the proposition that restricting reflection is going to 
happen, then it follows from that that (a) modules must be able to 
carefully control who has access, and (b) modules that do have access 
need a way to utilize it.

However it is also important that modules which grant access have a 
simple, non-verbose way to do so.  It is also important that exiting 
code should not have to jump through extra hoops to gain the same access 
they have always had - the module declarations should suffice for this 
purpose.

On 09/30/2016 09:11 AM, Sanne Grinovero wrote:
> Hi all,
> I think what Peter raises is a very interesting quandary.
>
> Without going in the syntax details of this proposal, the point is
> that implementations of "javax.persistence" (and similar APIs) need to
> advertise themselves as eligible to getting certain additional
> privileges - such as reflective access - which the platform is
> attempting to limit (why?).
>
> The problem I see is that it should be fairly easy for any library to
> fool the platform to obtain the same privileges; I could certainly
> extend Hibernate and make a new JPA provider in just minutes, and do
> something else with those additional privileges as well.
> This might be a clumsy trick, but sufficiently motivated people - such
> as those having malicious intents - could certainly entertain such
> plans.
> While well intentioned developers who have a legitimate reason to need
> reflective access - like plans to make some better framework ? - would
> need to write odd looking, time wasting code to get their work done.
>
> Wouldn't it be far easier to just allow reflective access to everyone
> without restrictions, at least on weak modules? I'm not seeing the
> benefits of preventing this - especially to people using the
> Reflection API.
>
> Thanks,
> Sanne
>
>
> On Thu, Sep 29, 2016 at 5:06 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi,
>>
>> Building on the idea presented here (the part that talks about method
>> ''assumeAccessOf'):
>>
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009520.html
>>
>> ...which tries to solve the problem that some modules have when they don't
>> know in advance the name of the module(s) to which to export its packages
>> for reflective access and they just want to export them to the selected
>> module(s) - i.e. use qualified exports.
>>
>> The canonical example here is an application module, say "app", that is
>> coded against an API module, say "javax.persistence" which just defines the
>> API, but at link or assembly time, the module that implements such API, say
>> "hibernate-core" is added which needs access to "app" classes using
>> reflection.
>>
>> The API module ("javax.persistence" in this case) usually also contains a
>> bootstrap (factory) class, which is responsible to bootstrap the API and
>> bind it to the implementation. In case of javax.persistence it is
>> javax.persistence.Persistence class with a static createEntityManagerFactory
>> method, which finds and instantiates an EntityManagerFactory implementation.
>> This point is an opportunity for javax.persistence module to delegate its
>> permissions to access classes in other modules to the module of the
>> implementation class:
>>
>>     public static EntityManagerFactory createEntityManagerFactory(String
>> persistenceUnitName, Map properties) {
>>
>>         Class<? extends EntityManagerFactory> emfClass = ...;
>>
>> Persistence.class.getModule().delegateAccessTo(emfClass.getModule());
>>
>>         EntityManagerFactory emf = emfClass.newInstance();
>>         ...
>>
>>         return emf;
>>     }
>>
>>
>> So for example, app module could export its entity package(s) to
>> javax.persistence module only:
>>
>> module app {
>>     requires javax.persistence;
>>     exports private app.entity to javax.persistence;
>> }
>>
>>
>> And the ability to access this package would be transferred to the
>> implementation module by the javax.persistence module. The implementation
>> module is in fact just an extension of the API module and the API delegates
>> to it or is extended by it.
>>
>> java.lang.Module instance method:
>>
>> public void delegateAccessTo(Module module) { ... }
>>
>> ...would be similar to addExports or addReads. It would only be possible to
>> call it from 'this' module (i.e. a module could only delegate access given
>> to it - not access given to any other module).
>>
>> When SecurityManager is present, then there would additionally have to be a
>> permission assigned to codesource of javax.persistence.Persistence class for
>> it to carry on the delegation.
>>
>>
>> I think this is safe and sound, and most importantly, self-managing.
>>
>> What do you think?
>>
>>
>> Regards, Peter
>>

-- 
- DML