How to export a package from a module in a boot layer to module in a child layer.

[Ron Pressler]

> On 31 Jan 2025, at 18:25, Code Ranger <coderanger2025 at outlook.com> wrote:
> 
> 
> 
> On 1/31/25 19:54, Ron Pressler wrote:
>>> 
>>> Unfortunately, this is correct.
>>> 
>>> I am sure, that if it is necessary to use agent and java instrumentation to make this the simplest configuration work, then it simply means, that something is wrong here. Maybe two many constrains?
>> Manipulating a module’s access checks at runtime allows you, for example, to redefine the value of 5 in Java to be 6, and that is precisely the job agents are, and have always been, for. Changing the internal rules by which the runtime operates — and modules’ access are at the core of these rules — is the very definition of low-level instrumentation.
>> 
>> Have you encontered a difficulty using this standard approach?
> Unfortunately, I cannot consider your example appropriate for the situation under discussion. We are not talking about changing 5 to 6, but rather about granting or modifying access to a module’s packages. By other words, I don't need 5 to be 6, I just need jline to work with jansi? Do you see the difference?
> 
> If the only solution is to use agent and there is no other normal, standard, elegant solution I want to be sure of it.

Using agents is and has always been the normal and standard solutions when Java’s internal rules and meaning are to be changed. Changing the inner workings of the JDK, however, is not elegant (no matter how it’s done), and is, therefore, done sparingly. When you ask for the power to change the value of 5 into 6 — which is what you’re asking for when you want to modify access to modules — it doesn’t matter whether or not you actually use that power. The runtime now must be aware that it cannot assume 5 means 5 anymore.

If you encounter a problem and come to believe that the only solution is to change the internal assumptions that the Java runtime wants to rely on, then yes, agents are the mechanism to achieve that.

But the problem here isn’t what you want. You’re saying that there is a basic library that cannot work unless Java's internal assumptions are changed. It’s easy to see that a library that asks that the laws of Java be changed for it to work is a problematic library. That’s the problem that needs to be solved. If indeed, as Alex writes, JLine’s authors have fixed the core issue, then it already has been solved.

> 
> Because, if this is the only solution then the following statement will be true - "If you have two layers and the most common library modules, to make it work YOU NEED TO USE AGENT AND JAVA INSTRUMENTATION".
> Something like that.


Your question seems to contain an assumption that AGENTS AND JAVA INSTRUMENTATION are somehow more intrusive or radical than "granting or modifying access to a module’s packages”. That is simply not the case. They are both equally intrusive and radical (it’s possible that code that can do the latter may be able to turn itself into an agent). To give you another exmaple, if you modify java.base’s access, the runtime cannot assume that any string in the entire program is immutable.

— Ron