On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman
<alan.bate...@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.
