On 05/10/2018 13:17, Rafael Winterhalter wrote:
:
However, for Java agents, there is still no good way to define
auxiliary classes. There is an open ticket on
https://bugs.openjdk.java.net/browse/JDK-8201784 and I have described
my concerns with the suggested API in the linked discussion as being
insufficient for many use cases. I still hope that a defineClass
method can be added to the Instrumentation interface; I would not know
of any other good use case that currently makes use of the internal
Unsafe version but agents.
As of today, Unsafe::defineClass is however still a crucial element
for many Java agents that are widely used in the enterprise space,
e.g. for APM tools, security monitoring or metrics extraction. Not
offering an alternative would lock out these tools and stop a large
fraction of Java users from updating their production environments
until a new workaround is found. I hope that you consider an API for
Java agents to define classes as a blocker issue to be solved prior to
removing Unsafe::defineClass alltogether.
There was a lengthy thread about this topic on serviceability-dev
earlier this year. As I'm sure you will remember, Mandy did propose
additions to the Instrumentation API to support defining of auxiliary
classes in the same runtime package as the instrumented class. The nice
thing about that proposal is that extended the Instrumentation API in a
way that is aligned with original purpose of this API. As I think we
explained several times, the Instrumentation API is to support tools
doing benign instrumentation. The Instrumentation API was never intended
to support some of the scenarios that you brought up in the discussion.
Yes, we understand that you are trying to support some "interesting"
use-case, esp. around mocking, but many of these scenario that are way
outside the scope of this API. We do need to get back to that discussion
but it's important to set expectations at the same time.
-Alan
