Alex, thank you very much for your suggestion and the link with important
information.
On 1/14/25 00:27, Alex Buckley wrote:
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.
Such a solution will lead to significant and unjustified complication of the
application. At the same time, it will still not be universal, as it does not
apply to JDK modules, which can only reside in the boot layer. A solution that
is not universal cannot be considered a good solution.
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).
I opened this issue https://bugs.openjdk.org/browse/JDK-8347283. In this issue
I suggest to open the boot layer controller ONLY to ONE module that is
specified by JKD parameter. For example, it can be
boot-controller-accessible-module. So, only this module will be able to use the
boot layer controller. From the link you provided:
We cannot treat the mere inclusion of an unsafe-using library or framework in
an application as consent by the application's developer to violate integrity.
The developer might not be aware that the component uses an unsafe API. The
developer might not even be aware that the component is present, since the
component could be an indirect dependency several layers removed from the
application itself. *The application developer must therefore explicitly
configure the Java runtime to allow selected components to use unsafe APIs.*
Please, pay attention to the last sentence. What I propose in the issue
(JDK-8347283) fully complies with these conditions.
To be honest, I don’t understand what the problem is. I am trying to provide
the ability to dynamically add directives to boot-layer modules with the full
consent of the application developer, without any restrictions like the
mandatory prior use of --add-* parameters (which obviously defeats the whole
idea of a dynamic approach). The ModuleLayer.Controller class has only four
methods (essentially 1 + 1 + 1 + 1). I refuse to believe that JDK developers,
who are clearly highly skilled and experienced programmers, cannot solve this
problem.
So, what’s the issue? Do we really want the instructions for adding a plugin in
Java to look like this:
1. Install the plugin.
2. Stop the application.
3. Add --add-exports ..., --add-opens ....
4. Restart the application.
Best regards, CR
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
