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

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 >

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

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

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

On 30/09/16 14:27, Rafael Winterhalter wrote: > A Java agent ends up on the class path. The Byte Buddy agent (or any > similar library) basically adds a single class: > > package net.bytebuddy.agent; > public class Installer { > public static volatile Instrumentation instrumentation; > public

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

A Java agent ends up on the class path. The Byte Buddy agent (or any similar library) basically adds a single class: package net.bytebuddy.agent; public class Installer { public static volatile Instrumentation instrumentation; public static void agentMain(String argument, Instrumentation

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

On 30/09/16 13:15, Rafael Winterhalter wrote: > Such a library exists already: > http://mvnrepository.com/search?q=byte-buddy-agent Ok, so problem solved :-) > 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

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

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

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

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 >>

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

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

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

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

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

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

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

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. In Mockito, we simply do not offer inline mocks (but subclass mocks) if the runtime attachment fails. EhCache or JOL

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

On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman wrote: >On 29/09/2016 18:50, Rafael Winterhalter wrote: > >> : >> >> Therefore I want to propose adding a static method to the >Instrumentation >> interface: >> >> interface Instrumentation { >>static

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

On 29/09/2016 18:50, Rafael Winterhalter wrote: : Therefore I want to propose adding a static method to the Instrumentation interface: interface Instrumentation { static Instrumentation getInstance(boolean redefine, boolean retransform, boolean nativePrefix) { // security manager

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

On 09/29/2016 07:50 PM, Rafael Winterhalter wrote: > I want to propose adding a method to the instrumentation API to receive an > instance of the current VM's instrumentation API. Currently, many > applications "self-attach" to gain such access. Unfortunately, this only > works on JDK-VMs but I

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

Hello, I want to propose adding a method to the instrumentation API to receive an instance of the current VM's instrumentation API. Currently, many applications "self-attach" to gain such access. Unfortunately, this only works on JDK-VMs but I believe that this approach will grow in popularity