<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Alex, thank you very much for your suggestion and the link with
important information.<br>
<br>
<div class="moz-cite-prefix">On 1/14/25 00:27, Alex Buckley wrote:<br>
</div>
<blockquote type="cite" cite="mid:87b70d59-8b43-4cc7-b22e-b47780b6873b@oracle.com">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.
<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite" cite="mid:87b70d59-8b43-4cc7-b22e-b47780b6873b@oracle.com">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"
(<a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8305968#Restrictions-on-standard-unsafe-APIs">https://openjdk.org/jeps/8305968#Restrictions-on-standard-unsafe-APIs</a>).
<br>
<br>
</blockquote>
I opened this issue <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8347283">https://bugs.openjdk.org/browse/JDK-8347283</a>. 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:<br>
<br>
<blockquote type="cite"><span style="color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">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. <b>The application developer must therefore
explicitly configure the Java runtime to allow selected
components to use unsafe APIs.</b><span> </span></span></blockquote>
Please, pay attention to the last sentence. What I propose in the
issue (JDK-8347283) fully complies with these conditions. <br>
<br>
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.<br>
<br>
So, what’s the issue? Do we really want the instructions for adding
a plugin in Java to look like this:<br>
<br>
1. Install the plugin.<br>
2. Stop the application.<br>
3. Add --add-exports ..., --add-opens ....<br>
4. Restart the application.<br>
<br>
Best regards, CR<br>
<br>
<br>
<blockquote type="cite" cite="mid:87b70d59-8b43-4cc7-b22e-b47780b6873b@oracle.com">Alex
<br>
<br>
On 1/13/2025 12:58 PM, Code Ranger wrote:
<br>
<blockquote type="cite">Alex, thank you for your suggestion.
<br>
<br>
Putting application in its own layer
<br>
1) is technically impossible, because the "CORE module" creates
child layers, including the child layer you are talking about,
<br>
2) gives nothing, because it doesn't solve the main problem when
child layer require adding directives to boot layer modules.
<br>
<br>
Best regards, CR
<br>
<br>
On 1/13/25 22:51, Alex Buckley wrote:
<br>
<blockquote type="cite">Mike/Code Ranger, the obvious suggestion
is to put your application (including the "CORE module") in
its own layer, rather than the boot layer.
<br>
<br>
Alex
<br>
<br>
On 1/13/2025 1:46 AM, Code Ranger wrote:
<br>
<blockquote type="cite">Hello, Alan
<br>
<br>
Thank you for your suggestions, help, and time. I truly
appreciate and am deeply grateful for them.
<br>
<br>
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.
<br>
<br>
Please, see
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://ibb.co/bLTzp0n__">https://urldefense.com/v3/__https://ibb.co/bLTzp0n__</a>;!!
ACWV5N9M2RV99hQ!
LnYA2Im1AFI5I96HdRK8cKttxczpYE2hMPXX9jrASNBXjyB7Um4AQQe5nSLytW1VWQYs7Wx_p4gvO2F6QrwcLVh6G0MYwg$<br>
If you have any questions, I’m ready to answer them, as I’ve
already mentioned, this matter is extremely important to me.
<br>
<br>
<br>
On 1/13/25 09:54, Alan Bateman wrote:
<br>
<blockquote type="cite">On 12/01/2025 09:12, Code Ranger
wrote:
<br>
<blockquote type="cite">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.
<br>
<br>
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.
<br>
<br>
2. Now, I tried to do apiModule.addOpens in CORE module.
I got:
<br>
<br>
java.lang.IllegalCallerException:
com.foo.api.packagename is not open to module
com.foo.core
<br>
at
java.base/java.lang.Module.addOpens(Module.java:918)
~[?:?]
<br>
<br>
<br>
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.
<br>
</blockquote>
<br>
Your second mail reveals a bit more but it's not clear if
your issue is one of these scenarios:
<br>
<br>
1. A serialization library that is incompatible with
strong encapsulation. If so, that's a different
discussion.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
-Alan
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>