How to open a package from a module in the boot layer to a module in another layer?

[Alex Buckley]

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://ibb.co/bLTzp0n
> 
> 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
>>
>>
>