Суббота, 13 октября 2018, 10:43 +03:00 от Alan Bateman <alan.bate...@oracle.com>: > >On 12/10/2018 21:57, Alex Sviridov wrote: >> Hi Alan, >> >> Thank you for detailed explanation. It is great that we have API that allows >> to implement >> such features. However, what I suggest is a little different. I am speaking >> about using >> existing code for such features. >> >> I think this way - firstly, we can do write the same code many times. We >> can, but we >> don't want. Secondly if we pass parameters to JPMS via JVM options to >> configure boot >> layer, it would be great if we had possibility to pass the same parameters >> to configure a >> custom layer without writing a line of code and use existing JDK code. >> >> Of course this is my person opinion. It is interesting to hear what other >> developers think. >> >I'm skeptical on both the feasibility and desirability of going there. >If a container is creating module layers at runtime then it is arranging >which modules are observable, e.g. it may choose one version of JAX-RS >for one configuration/layer, and another version for another >configuration/layer. In your scenario it may want to patch or augment >one of these modules. I don't think you can easily express this on the >command line as there isn't anything to identify the layer than you want >to adjust. I am sorry, maybe I didn't express this very clear: I mean something like this: ModuleLayer layer = parent.defineModulesWithOneLoader(cf, scl, args); Where args are for example String[] and we pass the same --add-exports, --add-opens, --patch-module, --add-modules, --add-reads etc that we pass to configure boot layer. The disadvantage of such way is using String. However, there are two main advantages: 1) no line of code 2) use the same parameters that we use to configure boot layer - one solution within one technology.
-- Alex Sviridov
