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.
