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

[Andrew Dinn]

On 31/01/2025 17:33, Code Ranger wrote:
> 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?

Hmm, it is not always good to be too sure about things. I believe there 
are two things you are assuming here that need revisiting.

1) The requirement to use an agent to achieve this is not a mistake 
rather a deliberate policy choice by project developers: if you want to 
make this sort of change to runtime behaviour you have to do so by 
explicitly employing the runtime mechanism that grants specially 
nominated Java code certain well-defined, extraordinary powers i.e. 
deploy an agent.

2) What you are asking for is not simply an API to perform some minor 
configuration management rather an API that opens up access to the 
normally closed world of JDK runtime internals i.e. one that is 
sufficient to do what you want but can also do a whole lot more.

Point 2 justifies point 1. You may think that point 2 goes overboard and 
  imposes an unnecessary escalation of requirements (point 1) on the 
programmer. However, there is a good reason to do it this way.

The specific API you are asking for might potentially be used to do only 
what you intend. Your code might only use it for that purpose. However, 
it might also be misused, by accident or subversion -- whether on your 
part or on the part of some 3rd party code,--  to prejudice the 
integrity of the runtime. Likewise for many other APIs that we might add 
which open up, piecemeal, various routes to some specific privileged 
access or other.

The current JDK/JVM design provides a small number of mechanisms that 
provide broad, privileged powers to open up access to JDK private APIs - 
agents is one, command line options are another. This design also 
provides a clear and simple mechanism for users to guarantee that these 
routes to privileged access can be closed off. If you don't open up 
modules on the command line, don't install agents on the command line, 
don't explicitly enable dynamic agent installs on the command line then 
these extra routes into the JDK are closed.

That design decision was made for two reasons. Primarily, it transfers 
the risk of opening up access to users who explicitly choose to do so on 
the command line rather than leaving the decision open to the vagaries 
of how their code and/or 3rd party library code has been written or, 
potentially, mis-written. Secondly, it allows the JDK and JVM to turn 
speculative optimizations that assume the certain parts of the JDK/JVM 
are closed to client code into optimizations based on *sure* guarantees.

In summary, this is a trade-off that we have deliberately chosen to skew 
towards guaranteed integrity for the majority of cases at the cost of 
increasing the design complexity for some special cases like yours.

regards,


Andrew Dinn
-----------