delegating module access

[Sanne Grinovero]

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
>