VirtualMachine in tools.jar

[Henri Tremblay]

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