You can split your application so that a small loader module goes in the
boot layer, while the bulk of the application (CORE module, API module,
etc) lives in a child layer. That child layer becomes the parent for the
plugins' layers. You are already resolving plugin modules (and their
dependencies, such as Gson) in the context of their own layers, so no
change there.
Exposing the boot layer's controller would allow arbitrary code to
export JDK packages without the use of --add-exports on the command
line. That's a non-starter, as discussed in "Integrity by Default"
(https://openjdk.org/jeps/8305968#Restrictions-on-standard-unsafe-APIs).
Alex
On 1/13/2025 12:58 PM, Code Ranger wrote:
Alex, thank you for your suggestion.
Putting application in its own layer
1) is technically impossible, because the "CORE module" creates child
layers, including the child layer you are talking about,
2) gives nothing, because it doesn't solve the main problem when child
layer require adding directives to boot layer modules.
Best regards, CR
On 1/13/25 22:51, Alex Buckley wrote:
Mike/Code Ranger, the obvious suggestion is to put your application
(including the "CORE module") in its own layer, rather than the boot
layer.
Alex
On 1/13/2025 1:46 AM, Code Ranger wrote:
Hello, Alan
Thank you for your suggestions, help, and time. I truly appreciate
and am deeply grateful for them.
However, I’m afraid I failed to convey the most crucial point.
Therefore, I decided to illustrate it graphically. I believe
everything will become clear now.
Please, see https://urldefense.com/v3/__https://ibb.co/bLTzp0n__;!!
ACWV5N9M2RV99hQ!
LnYA2Im1AFI5I96HdRK8cKttxczpYE2hMPXX9jrASNBXjyB7Um4AQQe5nSLytW1VWQYs7Wx_p4gvO2F6QrwcLVh6G0MYwg$
If you have any questions, I’m ready to answer them, as I’ve already
mentioned, this matter is extremely important to me.
On 1/13/25 09:54, Alan Bateman wrote:
On 12/01/2025 09:12, Code Ranger wrote:
1. I see that JDK-8347283 was closed with your comment. I don't
agree with you decision, but I can be wrong. Let me explain, why I
think that is wrong using this concrete example.
Boot layer has jdk modules and main application modules. The CORE
module of the application creates plugins with child layers. No one
in the world can know what plugins will be created and used when
the main application starts. Now, somewhere in the future, the
module A from plugin X will require module B from boot layer to
open its package to module A. I believe, that the only solution to
do it is to provide the controller of the boot layer.
2. Now, I tried to do apiModule.addOpens in CORE module. I got:
java.lang.IllegalCallerException: com.foo.api.packagename is not
open to module com.foo.core
at java.base/java.lang.Module.addOpens(Module.java:918) ~[?:?]
Therefore, as far as I understand, for the solution you are
suggesting to work, the packagename package of the API module must
be opened to the Core module. But the main problem, as I've said
above - no one knows in advance which packages of which modules
from the boot layer will need to be opened/exported, etc., to the
plugins that will be created by users and deployed dynamically.
Your second mail reveals a bit more but it's not clear if your issue
is one of these scenarios:
1. A serialization library that is incompatible with strong
encapsulation. If so, that's a different discussion.
2. The API and CORE modules have some interesting internals that the
authors of these modules have chosen not to export. The author of a
plugin doesn't agree. As you've found, this can only be facilitated
with cooperation from code in CORE. It may additionally require CLI
option if API won't open its packages to CORE. This means running
with --add-opens API/com.foo.api=CORE so that CORE can open API's
package to the plugin module in the child layer.
3. A badly behaved plugin that depends on the internals of standard
or JDK modules. This would be whack-a-mole and require a combination
of CLI options and code in CORE to open java.* and jdk.* packages to
the offending code in the plugin.
-Alan
