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
