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.bate...@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 >
