two or more jvm in a single machine

[santoshjoshi2003]

hi can there be two JVM in a single machine if yes please provide me
the details

 

[Nigel Wade]

hi can there be two JVM in a single machine
Yes.

if yes please provide me
the details

What details do you want?
Each invocation of java creates a new JVM in a completely independent process.

 

[Joshua Cranmer]

What details do you want?
Each invocation of java creates a new JVM in a completely independent process.

Not entirely true. JVMs share memory space, so the same class versions
and static variables stay constant throughout the computer.

 

[Thomas Schodt]

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

Not entirely true. JVMs share memory space, so the same class versions
and static variables stay constant throughout the computer.

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

 

[ck]

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

Not entirely true. JVMs share memory space, so the same class versions
and static variables stay constant throughout the computer.

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

set a system variable called JAVA_HOME to point to your jdk folder
(which contains the bin folder)
add %JAVA_HOME%\bin to PATH

If you have JDK 1.4 in (lets presume) c:\java\jdk1.4
and JDK 1.5 in d:\java\jdk1.5
To test JDK 1.4 set JAVA_HOME= c:\java\jdk1.4
and to test JDK 1.5 set JAVA_HOME=c:\java\jdk1.5
It is not necessary to install either of JDK (1.4 or 1.5)
You can copy the jdk folder from any other place where these jdk are
installed
If you are going to test it in command prompt, make sure that you open
a new command prompt after each change
Or you can set it using set command in the command prompt.

 

[Chris Uppal]

Not entirely true. JVMs share memory space, so the same class versions
and static variables stay constant throughout the computer.

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

 

[Lew]

set a system variable called JAVA_HOME to point to your jdk folder
(which contains the bin folder)
add %JAVA_HOME%\bin to PATH

If you have JDK 1.4 in (lets presume) c:\java\jdk1.4
and JDK 1.5 in d:\java\jdk1.5
To test JDK 1.4 set JAVA_HOME= c:\java\jdk1.4
and to test JDK 1.5 set JAVA_HOME=c:\java\jdk1.5
It is not necessary to install either of JDK (1.4 or 1.5)
You can copy the jdk folder from any other place where these jdk are
installed
If you are going to test it in command prompt, make sure that you open
a new command prompt after each change
Or you can set it using set command in the command prompt.

A less Windows-centric approach is to use symlinks (or the alternatives
mechanism available in Linux) to make a canonical path reference that is flexible.

-- Lew

 

[Nigel Wade]

Not entirely true. JVMs share memory space, so the same class versions
and static variables stay constant throughout the computer.

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.