Because Java was planned to be both cross-platform mobile and secure, it isn't run directly on the computer's CPU (or on its operating system). When a Java program is compiled it's turned into byte-code – a machine code for the Java Virtual Machine, or JVM. The Java virtual machine is what runs the Java program's threads, allocates memory for it, etc. If properly done, this lets the code run on any platform implementing a standard JVM, and doesn't let the code directly access system resources, thus letting the user modify security levels.

While the JVM, being a virtual machine, is a software construct, it's a model (or emulation) of a real piece of hardware.
With this in mind, it's interesting to note that J(v)M has an entirely stack based architecture. There are no registers available to the programmer.(This means that all operations have to access memory) This is very much contrary to the present trends in CPU design, where everyone's adding more registers.
Now, if Java were originally concieved of as the internet/universal platform it's generally viewed as, the idea of basing everything on the stack model would make sense. Minimizing the number of registers used would allow a simple and fast implimentation, regardless of the number of available on the host platform.
However, Java was originally intended to be used for embedded applications. Looked at in this light, it was a way of getting the simplicity and cost reduction of a RISC design, without the cost and trouble of adding all those registers. (see cop out)