And, in case OP means two JRE or SDK installations,
also yes.

Only since Sun Java 1.5, and only for system classes
[<http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html>]
unless Sun changed this for Java 1.6

The way you phrase it makes it sound as if there's some sort of overlap, where
operations in one JVM could affect code running in another one (e.g. changing a
static variable).  /Nothing/ which could possibly be detectable to even the
lowest level Java code (or even JNI) is, or can be, shared between JVMs.  In
particular, JVMs do not share their address spaces (though that may not have
been what you meant by "JVMs share memory space").

There /are/ options for a certain amount of sharing of code (not Java code, and
the JVM implementation itself), and data (but not data accessible to Java
programs) between JVMs, but that's a matter which is entirely private to the
JVM and OS between them.  Its just a special case of the fact that most OSs can
arrange to have a certain amount of code/data shared (invisibly) between
separate invocations of the same code (same .exe or same .dll); and that with a
bit of care from the programmers can arrange to share a certain amount of
dynamically loaded, read-only (or copy-on-write), data too.

So, the original advice (quoted above) is essentially correct, and is entirely
correct for anything relating to the semantics of Java programs.

   -- chris

JVMs don't share memory space. Each JVM is an entirely separate process with its
own virtual memory address space, and has its own classloader and heap. The JVM
will almost certainly contain native code comprising shared libraries which
will share native code. These shared libraries may have static data within them
which can be shared, but this is not Java class static data.

The classes, and any class static data within them, are loaded separately by
each JVM into memory which is not shared between processes.