-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
Module layers can be used (and maybe are primarily used) for programs that create their subsystems, plugins, components, extensions dynamically. Such programs have the following layers:
1) boot layer: framework + standard (JRE/JDK) modules
2) child layers [with child layers..] where every child layer is a dynamically added plugin/component.
However, there is one very serious problem due to two factors: 1) as plugins/components are created dynamically it is not known what standard modules will be required for them when boot layer is created 2) currently it is not possible to add standard modules to child layers.
The only workaround for this problem is to add ALL standard modules to boot layer and it is recommended to do via --add-modules ALL-DEFAULT parameter.
As an example let's suppose that there are two custom modules - framework and plugin (requires java.xml). So totally there are 4 modules: java.base, framework, plugin and java.xml. For plugin a child layer is created. This solution will look this way https://i.stack.imgur.com/3CWPb.png
As you see there are about 50 modules in boot layer that can be never used. The most interesting thing is that when boot layer is created JPMS removes modules that are not directly required even if a user tries to add them (as I understand for optimization). To force JPMS to add them it is necessary to use --add-modules.
That's why I suggest to add possibility to add standard (JRE/JDK) modules to child layers. If this feature is fixed then the example with framework and plugin will look this way - https://i.stack.imgur.com/mwD5n.png
The difference is obvious. I don't think that this issue will require any changes in API. Layers will still be immutable. The API for creating layer will be the same as when child layer is created only custom modules will provided by user. JPMS will resolve what standard modules to add itself.
This issue was also discussed in jigsaw mailing list - https://mail.openjdk.org/pipermail/jigsaw-dev/2024-January/015008.html
Module layers can be used (and maybe are primarily used) for programs that create their subsystems, plugins, components, extensions dynamically. Such programs have the following layers:
1) boot layer: framework + standard (JRE/JDK) modules
2) child layers [with child layers..] where every child layer is a dynamically added plugin/component.
However, there is one very serious problem due to two factors: 1) as plugins/components are created dynamically it is not known what standard modules will be required for them when boot layer is created 2) currently it is not possible to add standard modules to child layers.
The only workaround for this problem is to add ALL standard modules to boot layer and it is recommended to do via --add-modules ALL-DEFAULT parameter.
As an example let's suppose that there are two custom modules - framework and plugin (requires java.xml). So totally there are 4 modules: java.base, framework, plugin and java.xml. For plugin a child layer is created. This solution will look this way https://i.stack.imgur.com/3CWPb.png
As you see there are about 50 modules in boot layer that can be never used. The most interesting thing is that when boot layer is created JPMS removes modules that are not directly required even if a user tries to add them (as I understand for optimization). To force JPMS to add them it is necessary to use --add-modules.
That's why I suggest to add possibility to add standard (JRE/JDK) modules to child layers. If this feature is fixed then the example with framework and plugin will look this way - https://i.stack.imgur.com/mwD5n.png
The difference is obvious. I don't think that this issue will require any changes in API. Layers will still be immutable. The API for creating layer will be the same as when child layer is created only custom modules will provided by user. JPMS will resolve what standard modules to add itself.
This issue was also discussed in jigsaw mailing list - https://mail.openjdk.org/pipermail/jigsaw-dev/2024-January/015008.html