Such a library exists already:
http://mvnrepository.com/search?q=byte-buddy-agent
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. It is my opinion that adding such an API would
only improve the situation compared to today. In this light, calling
ByteBuddyAgent.install() is a less secure way of calling the proposed
Instrumentation.getInstance().
I understand that this needs to be assesed thoroughly but I still hope this
proposal is not dismissed prematurely.
Best regards, Rafael
Best regards, Rafael
2016-09-30 13:51 GMT+02:00 Andrew Dinn <ad...@redhat.com>:
> On 30/09/16 10:37, Alan Bateman wrote:
> > On 30/09/2016 09:39, Rafael Winterhalter wrote:
> >
> >> I agree that this should be considered carefully.
> >>
> >> However, without a security manager, it is already possible to get
> >> such an instance for most environments. And starting with Java 9, this
> >> will extend to non JDK-VMs as the former tools.jar is now a module.
> > Assuming you mean the jdk.attach module then it's JDK-specific. It's not
> > linked into the runtime image that is the JRE for example.
> >
> > In any case, this proposal is a significant concern as it is exposing
> > capabilities in the standard API that were intended for tool agents. The
> > implications are huge.
>
> I agree with all Alan's concerns here.
>
> Also, although many developers have used the attach API to self-hoist
> an agent into a JVM (Byteman also does this when used with JUnit/TestNG)
> and have, perhaps, re-implemented the same wheel to do so I don't think
> fixing that circumstance really merits a JVM change. A couple of small
> library jars could address this problem, shrink-wrapping the necessary
> functionality into a common API.
>
> The first jar could provide a class with a getInstrumentation() method
> which drives the attach API, loading the 2nd agent jar (which it can
> locate from the classpath).
>
> The agent jar can securely hand over the Instrumentation instance to the
> API class provided in the first jar allowing it to be returned to the
> caller.
>
> If these 2 jars were posted for common use (e.g. to Maven Central) then
> the functionality can be made available simply by adding the required
> jars to the classpath and calling the getInstrumentation() method.
>
> 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
>
