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

[Rafael Winterhalter]

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. I think by adding
such a method, security would improve as current solutions often use their
privileged access to read such an instance but often leave this instance
exposed in a public field reachable via the system class loader. I think by
including such a method, one could avoid the spreading of custom libraries
(like mine) that do self-attachment and properly secure the access via a
security manager.

Thank you for considering this!
Best regards, Rafael

2016-09-30 10:31 GMT+02:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 29/09/2016 20:37, Rafael Winterhalter wrote:
>
> It would be perfectly fine, in my opinion, to throw an unsupported
>> operation exception, if the feature was unsupported. The method would
>> primarily be used by testing code and tools.
>>
>> Right, but it essentially means that anything that use
> Instrumentation.getInstance(...) can dynamically extend the class path,
> add to the boot class loader search, redefine any class or module, ...
>  Assume the common case where there is no security manager and not using
> JDK-specific APIs. So I think this requires a lot of consideration before
> going any further - the original intention with this API is that it was for
> tool agents and this is why a method like the proposal method has been kept
> out of the API.
>
> -Alan
>