Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass

Alan Bateman Alan.Bateman at
Fri Oct 5 13:53:05 UTC 2018

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 
> 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.


More information about the core-libs-dev mailing list