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

[Rafael Winterhalter]

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 also fall back to not offering the related feature. Adding
the method would simply add convenience and security to something that is
already done by many libraries and tools out there.

Also, all major VMs do support it as of today as far as I know. (The
exception being J9 which currently has an unfortunate bug that triggers an
internal assertion error upon retransformation.)

Am 29.09.2016 9:22 nachm. schrieb "Remi Forax" <forax at univ-mlv.fr>:

>
>
> On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman <
> Alan.Bateman at oracle.com> 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 Instrumentation getInstance(boolean redefine, boolean
> >retransform,
> >> boolean nativePrefix) {
> >>      // security manager check
> >>      return getInstance0(redefine, retransform, nativePrefix);
> >>    }
> >> }
> >>
>
> I've a code that also does that for implementing a Repl like JShell.
>
> >The original intention, back in JSR 163, was that java.lang.instrument
> >be for instrumentation agents, not applications. This is why the API
> >deliberately does not include a method to get the Instrumentation
> >object
> >along the lines you have propose. Sure, you can leak it from an agent
> >started on the command line or attached at runtime but that is not the
> >original intention. So I think introducing this method is a very
> >significant change that would require a lot of consideration (previous
> >requests to provide a way for applications to get the Instrumentation
> >object without an agent in the picture were resisted).
> >
> >Separately, introducing this method creates a complication for runtimes
> >
> >that do not have JVM TI support (the JPLIS agent is based on JVM TI).
> >As
> >things stand then it's possible to create a runtime that does not have
> >a
> >means to start agents from the command-line (the spec allows this) and
> >so there is no need to have the implementation support for this API. So
> >
> >if a method like this is every introduced then it would either have to
> >be optional or it would require changes to the JVM TI spec to make it
> >non-optional (or is based on an alternative JPLIS implementation that
> >doesn't use JVM TI).
>
> Having it optional seams fine.
> Perhaps it has to be activated by a command line argument too.
>
> >
> >-Alan
>
> Rémi
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>