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.lev...@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
