From adinn at redhat.com Mon Feb 3 10:31:37 2025 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Feb 2025 10:31:37 +0000 Subject: How to export a package from a module in a boot layer to module in a child layer. In-Reply-To: References: Message-ID: <02a2d7d2-5a91-4924-8a52-6ef0a29b2ee7@redhat.com> 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 -----------