Privileged module idea

[Nikita Lipsky]

Hi,

Thank you for your feedback. It is positive so far.
I would like to listen also any critics from Jigsaw developers.

Meanwhile I have found myself one essential weakness of this approach. 
Some JPA/DI frameworks not only wire application code via reflection, 
they also generate bytecode at runtime that in particular may extend
application classes or have some other access to them.
Examples are Spring AOP and Hibernate. So reflective access may be not
enough for them. 
In current state of the module system, when you need to export classes
that may be accessed via reflection by frameworks 
this problem is solved because all generated bytecode falls into unnamed
module 
that by definition can read all exported types of other modules 
and hence can directly access them via bytecode references. 
If we do not export classes this approach fails because unexported
classes cannot be accessed even from unnamed module. 
So to solve this we need to either make unnamed module super privileged
so it can access all types at all 
or define some other super-privileged area in a module layer where
generated bytecode can access to what it needs.
In any case it breaks whole program optimizations opportunity because,
for example, we cannot treat unexported classes that are not extended as
final classes.

This turns me into thoughts that we need to better describe the
phenomena of frameworks that essentially rely on ability to manipulate
with user code 
via reflection and bytecode generation.
So let us think about the nature of this phenomena. I claim that
exporting types for frameworks to let them manipulate with such types is
bad idea in general.
Export of a module means that the module provides some public interface
to modules that *depend* on it. 
It is not the case for export for frameworks. Frameworks DO NOT actually
depend on such types, quite contrary user module code depends on
frameworks explicitly annotating that this particular code is
wired/manipulated with an external framework.
This leads me to a thought that we actually need an ability to describe
complimentary pairs: framework modules / modules that use frameworks.
How to name such modules is a question. Variants: privileged/weak,
master/slave (not sure about PC of such variant), manager/managed. 
Let us choose the latest variant for now to not collide with current
"weak modules" proposal. Thus:

"manager module" reads all types of "managed modules" by definition.
And "managed module" provides all types for any access to "manager
modules".
Unnamed module has to be "manager module" in this approach.
We can also require that "manager module" cannot require "managing
modules" in its "requires" clauses.
It is natural because "manager module" should not have any direct
references to modules that it manages (it should not depend on them).

This approach strengthens weakened strong encapsulation of "weak
modules", because "managed modules" can still have "export" clauses for
not-manager modules.
Thus it solves "framework phenomena" better way than "weak modules",
IMHO.

Any feedback?

Regards,
Nikita


-----Original Message-----
From: Oliver Gierke [mailto:ogierke at pivotal.io] 
Sent: Friday, October 14, 2016 4:40 PM
To: Nikita Lipsky
Cc: jigsaw-dev at openjdk.java.net
Subject: Re: Privileged module idea

Hi,

I like the idea. Especially the aspect that it allows you to identify
which of the modules have privileged access at runtime.

Also I guess it might even allow only certain modules of e.g. Spring to
actually require that access, i.e. only the ones that perform bean
instantiation etc. Not sure about the breadth of that effect but at
first glance it sounds like it might be worthwhile fleshing out the
details of your suggestion (how do modules declare they want to be
privileged ones? etc.)

Cheers,
Ollie

> Am 14.10.2016 um 04:27 schrieb Nikita Lipsky
<nlipsky at excelsior-usa.com>:
> 
> Hi all,
> 
> 
> 
> Recently I have described an idea of "privileged module" -- 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009636.
> ht
> ml
> <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009636
> .h
> tml>  :
> 
> 
> 
> "privileged module" may reflect on any unexported (and exported) type 
> of other resolved modules of a layer that it belongs to.
> 
> DI/JPA frameworks are subjects for "privileged modules".
> 
> 
> 
> "Privileged module" moves responsibility of weakened strong 
> encapsulation from user modules (via weak module or dynamic export
> concepts) to framework modules.
> 
> 
> 
> I would greatly appreciate if someone could give me any feedback on
it.
> 
> 
> 
> Regards,
> 
> Nikita
> 
> 

--
/**
 * @author Oliver Gierke - Senior Software Engineer
 *
 * @param email ogierke at pivotal.io
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */