On 16/04/2021 17:40, Rafael Winterhalter wrote:
:
I will try to make my case on the mailing list. I hoped this could get resolved
within the release of Java 17 as this would make it possible to write agents
without use of Unsafe API to support Java 17 and later. Since agents often are
supplementary to a broad range of Java applications, the LTS release will
likely be an important support boundary for years and years to come.
"are supplementary to a board range of Java applications" is part of the
concern with the proposal. If possible, it would be good if the write-up
could separate the requirements for injection/instrumentation by
frameworks at runtime from the requirements of tool agents. If the
requirements cover testing time and mocking then it would useful to
separate those too.
Just to add to Rémi's comment: For frameworks/libraries, the
Lookup.defineClass and defineHiddenClass APIs are to define classes in
the same run-time package as the Lookup class. There isn't any API for
libraries/frameworks to define class in a "new run-time package".
There's a chunky project there. Part of it is the Lookup API itself,
part of is that there isn't an exposed way to extend the set of packages
in a named module. Mandy has done some exploration on this topic and may
be able to say a bit more about this.
On Java agents, then I think the discussion will eventually lead into
putting at least some restrictions on agents loaded into a running VM.
Agents started on the command line with -javaagent are all-powerful but
maybe agents loaded into a target VM get a restricted Instrumentation
object that cannot redefine modules or retransform classes in named
modules. The narrower requirement for agents doing load time
instrumentation to define auxiliary classes in the same package as the
class being loaded fits with the intent of the original API and I don't
think is controversial.
-Alan
