> On 18 May 2023, at 23:52, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: > >> >> By “restricted” we mean “disallowed by default unless the application allows >> it.” We try to use that terminology consistently. In this JEP we’re just >> “preparing to restrict”, which means that unless explicitly allowed by the >> flag, there will only be a warning. > > Understood… but the question remains. If I understand this correctly, the API > in question java.lang.instrument.Instrumentation. What in that API would be > restricted? Are there other APIs that might be affected? >
That entire API will be restricted in the sense that it will require the application’s approval in the form of a -javaagent flag or the -XX:+EnableDynamicAgentLoading (or some other tool authentication mechanism we may come up with). The informational JEP says what else we plan to restrict (and I really, really recommend you read it carefully if you’re interested in this subject). In particular we plan to restrict JNI and its replacement, FFM, and to restrict or, preferably gradually remove Unsafe. However, JEP 451 says that if there’s sufficient demand we may offer the Instrumentation API not only to agents but also to libraries, in which case the Instrumentation object given to libraries will be subject to the “opens” restriction; i.e. a library module will be able to transform/redefine classes in modules that are open to it. The Instrumentation object given to agents is not subject to “opens” restrictions because agents, unlike libraries, are granted unlimited superpowers by the application. — Ron
