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:ogie...@pivotal.io] Sent: Friday, October 14, 2016 4:40 PM To: Nikita Lipsky Cc: jigsaw-dev@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 <nlip...@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 ogie...@pivotal.io * @param phone +49-151-50465477 * @param fax +49-351-418898439 * @param skype einsdreizehn * @see http://www.olivergierke.de */
