Java Language was designed as a portable programming language. The portability was supported by having the compiler produce bytecodes for a hypothetical architecture rather than real computer instructions. These bytecodes are interpreted by a piece of software called the Java Virtual Machine, JVM or (as here) the Java VM.
It's called a Virtual Machine because although it is a program which interprets bytecodes, it performs very much the same way that a real machine [computer] interprets its binary instruction set.
Implementing the JVM on a new computer suffices to move Java to that architecture, because of the availability of existing Java -> JVM bytecode compilers.
Erm... what about native code? The native code used by some of Java's standard libs are not given freely, hence a JVM would not suffice.
ISBN: 1-56592-194-1, Java Virtual Machine, by Jon Meyer & Troy Downing
ISBN: 0-20143-294-3, The Java Virtual Machine Specification (second edition) available online at java.sun.com 
Also, another book on the JVM by Bill Venners, at
www.artima.com
I find it interesting that there is still not a (complete) implementation of a Java Virtual Machine in the Java Language. Besides the theoretical side of such a thing, it would give an easy way to run multiple java applications in a single virtual machine, taking a different approach from the Echidna project. Any thoughts into why this has not been done? -- Adam Berger
Since Java is Turing Complete, obviously it would be possible in some sense. But Java is not a System Programming language, and does not pretend to be. It is unsuitable for implementing industrial strength compilers, interpreters, operating systems, device drivers, etc.
Would you really want e.g. pointers added to Java? Didn't think so.
A JVM written in Java would, however, have pedagogical value. I would think someone would do it eventually.
Perhaps it might be more tractable to implement a "function evaluator" in Java, as opposed to a full implementation. Such a function would depend on the underlying runtime (VM or native) for things such as garbage collection and the like.
Not sure it would be useful... but that doesn't stop folks
Implementing the JVM on a new computer suffices to move Java to that architecture??
Implementing a JVM on a new computer does not suffice. Sun has crippled Java by refusing to release the technology, instead insisting on continuing to bolt on large ungainly API layers heavily reliant on native code bases and copyrighted to perpetuate its control on a technology that offered so much in its original incarnation. -- Simon Armstrong
I need Sun JRE on my Windows Xp to run some of the free tools from Source Forge. On the other hand I know there are other websites that rely on Micro Soft Jview specific features. How can both versions of Java runtime be set active on the machine, and let the tools/websites choose what it needs?
Thanks for help -- David Liu
I've yet to see a really critical Java program that relies on the MS Java VM. That aside, since a certain lawsuit MS lost, its virtual machine is discontinued, discouraged, and generally evil. My personal solution to that problem would be either not using said programs at all, or bugging the website owners to redo the programs for Sun's VM. I don't think there's an easy way to use the two versions side-by-side. Windows determines the default way to open a document by the file extension, which is the same for any java program, be it distributed as classes, or as JARs. For .jar files, you could possibly rename them to something like .msjar, and have them opened with the MS VM, but that's as far as you can get.
If other programs invoke Java components, I'd bet they just execute java.exe, which is searched in the PATH environment variable paths, and as for applets, they are ran by the browser and the Java plugin installed in it - the website has little to say in the process, and for the browser, an applet is an applet is an applet - since the two VM implementations were supposed to be compatible and interchangeable, I don't think it's possible to disambiguate which one an applet was supposed to run in from the HTML.
See also Hot Spot, members.fortunecity.com (decompiler)
See original on c2.com