Lack of "export dynamic" requires to export everything for existing frameworks

[Nikita Lipsky]

I believe it would be better to introduce a concept of "privileged
module" instead of introducing "weak module" concept.

"privileged module" can reflect on any unexported (and exported) type of
other resolved modules of a layer that it belongs to.

In addition, we can introduce command line flags that would restrict
access of "privileged modules" to some modules 

or even a property for other modules that they are not subject for
privileged access. 

DI/JPA frameworks are subject for "privileged modules".

 

Why "privileged module" is better than "weak module" or "dynamic export"
concepts?

 

Weak module concept gives up "strong encapsulation" requirement at all.

It is introduced as workaround for DI/JPA frameworks for easier
migration

and has very big risk that developers would use it by default without
moving to strong modules at all.

"dynamic export" also weakens "strong encapsulation" of a module to ALL
other modules

while only a FEW of them can really require access to it via reflection.

And it can be not evident for developers what packages should be
dynamically exported

as they may not aware how particular DI/JPA frameworks work.

And as mentioned by Sander, qualified exports do not solve the problem
in general too.

 

"Privileged module" moves responsibility of slowed strong encapsulation
from user modules to framework modules.

It can be used for easier migration as well, so if I see that one module
occasionally accesses to another via reflection

and I cannot change export clauses of that module I can temporally make
my module privileged to workaround this situation.

However in general only a few modules on module-path should be
privileged and developers should have clear understanding

why those modules are privileged.

 

Further, we can make unnamed module privileged. It immediately solves
almost all backward compatibility issues regarding Jigsaw

(else there is chance that everyone will use Rafael's agent workaround).

On the other hand, we can intentionally make unnamed module not
privileged to motivate developers to move to modules

as only named modules will have such a great feature.

 

Whether privileged modules can access bootstrap (JDK) modules are
subject for discussion. In general, it can be also configured by a
module property.

 

We can also introduce "dynamic privileged module" and "privileged
module" concepts.

Here "privileged" means "unrestricted read" of all other modules, while
"dynamic privileged" only reflects other modules.

However, I think it is not needed as only reflective access is a real
problem and "unrestricted access" should be avoided by any means.

 

Nikita

 

I have just joined the jigsaw-dev mailing list so probably I have
reinvented the wheel.

If you had already a discussion regarding it, please give me a link why
the idea was rejected.