On 30/09/16 14:55, Rafael Winterhalter wrote:
> That does not work in the general case but only if the initiating class
> is also on the class path. A class can only be identified uniquely as a
> pair of name and class loader.
>
> I experimented with this and ended up iterating over
> Instrumentation.getAllLoadedClasses which resulted in rather poor
> performance and ambiguity if there exist classes with the same name on
> different class loaders.
Yeah but don't you still have your ByteBuddy API class, the one which
initiates the load in the class path? Your agent can still push the
instance to that class by calling a setter it provides and it can hand
the instance out to classes which are allowed to use it.
So, then you would have to stop any old clients from calling your API to
retrieve an Instrumentation instance, for example by setting up a
security manager. Otherwise it makes no difference whether the
Instrumentation instance is accessible via a public static field or is
handed out on demand by your API. You have set up this circumstance by
providing a library which hands out an Instrumentation instance on demand.
What I don't understand is why you think migrating this into the JDK
changes things. You suggested that this would also need a security
manager to control access. If that's needed to safeguard the API on
Instrumentation then why is i tnot good enough to use the same mechanism
to restrict access to your ByteBuddy API class?
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
