VirtualMachine in tools.jar

[Henri Tremblay]

I'm back on this topic.

After a little experiment, it appears that VirtualMachine is available by
default in the JDK 9. It is in the jdk.attach module. Which I guess is
loaded by default.

So, in fact, to work on JDK9, no tools.jar is needed.

Is my analysis right?

The code to give it a shot is just:

public static void main( String[] args ) throws Exception
{
    VirtualMachine vm = VirtualMachine.attach("42094");
    try {
        //...
    } finally {
        vm.detach();
    }
}


On 25 August 2015 at 11:16, Henri Tremblay <henri at tremblay.pro> wrote:

> David, thanks a lot for your answer. In fact, I dumbly haven't tried on
> jdk9 to see how it behaves. I will and give you feedback.
>
> I just felt on a weird asymmetry and felt it could be addressed by Jigsaw.
>
> I'm not sure I agree with Andrew but I don't have the necessary knowledge
> on that topic to be a good judge. So I will rephrase my first statement
> hoping it will now be intelligible.
>
> There are two ways to retrieve JMX information with another process.
>
>    - Remotely. This is only possible when jmx remote is enabled
>    explicitly by the process we are connecting to
>    - Locally. This is always possible. A local process can connect to
>    another using its PID. It should also run under the same user (previously,
>    it was possible to also be root but due to a JDK change, this isn't working
>    that well anymore. I can find the exact change if needed)
>
> The API to connect locally used to be available in tools.jar. We can
> connect remotely without tools.jar.
>
> This is the asymmetry I'm talking about.
>
> Connect locally is used by many monitoring tools: VisualVM, jstatd,
> jmxtrans, jmxterm. It is a useful feature because it prevents triggering
> all the JMX remote machinery.
>
>
> On 25 August 2015 at 05:12, Andrew Dinn <adinn at redhat.com> wrote:
>
>> On 25/08/15 08:58, Alan Bateman wrote:
>> > If I understand Henri's mail correctly then he is advocating that the
>> > attach API be included in the JRE builds. The attach API was developed
>> > as an API for tools so this is why it has always been in the JDK builds
>> > and not the JRE builds. Maybe there are new use-cases now that mean it
>> > should be re-examined but it's not clear from the original mail. In
>> > general, there are many interesting tools and tool APIs in the JDK
>> > builds that might sometimes be useful in environments that only have a
>> > run-time installed so I guess a similar argument could be made for those
>> > too.
>>
>> I think the attach classes are a very special case and there are
>> extremely important security reasons for not having the attach API
>> classes in the JRE as the normal case. Their presence in a runtime poses
>> the threat of exploding a small security hole into a gaping breach
>> (since the attach mechanism could be used by rogue code to install a
>> JVMTI Java agent into the current JVM -- with game over consequences).
>> Any runtime that is going to load code that needs to be constrained
>> (e.g. a browser running stuff like applets) probably doesn't want these
>> classes to be in the runtime. I know there are other ways of restricting
>> access but I believe the status quo is belt and braces.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in UK and Wales under Company Registration No. 3798903
>> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
>> (USA), Michael O'Neill (Ireland)
>>
>
>