Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

Rafael Winterhalter rafael.wth at
Fri Sep 30 13:27:28 UTC 2016

A Java agent ends up on the class path. The Byte Buddy agent (or any
similar library) basically adds a single class:

package net.bytebuddy.agent;
public class Installer {
  public static volatile Instrumentation instrumentation;
  public static void agentMain(String argument, Instrumentation
instrumentation) {
    Agent.instrumentation = instrumentation

Since the class is added using self-attachment, the agentmain method is
called by the VM and the field value is set. In order to keep the field
accessible, it needs to be public such that any class loader can call:

Instrumentation instrumentation = (Instrumentation)
Class.forName("net.bytebuddy.agent.Installer", false,

Any library on the class path can now also call the above code without
requiring any priviledges as the Instrumentation instance is exposed
without constraints. Adding a proper method for reading an instance of
Instrumentation would prevent this.

2016-09-30 15:14 GMT+02:00 Andrew Dinn <adinn at>:

> On 30/09/16 13:15, Rafael Winterhalter wrote:
> > Such a library exists already:
> >
> Ok, so problem solved :-)
> > I do however not share your point of view on this: if there is a valid
> > use case for self-attachment - Aleksey, you and I already named several
> > such use cases - why not add convenience, security and performance to
> > the API? Right now, a library can already self-attach when there is no
> > security manager but will always expose the Instrumentation instance
> > accessibly on the system class loader.
> I am not really sure what you mean by "will always expose the
> Instrumentation instance accessibly on the system class loader". Are you
> talking about reflective access from classes loaded by the system class
> loader? or do you mean something else?
> regards,
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the core-libs-dev mailing list