To help clarify the role of the Java interpreter, consider a hypothetical interpreter for a human language. Pretend you only speak French and your word processor only understands French. Let us also assume that someone has written you a letter in English.
In order to process the English letter your word processor would need an English-to-French translator, or interpreter. The job of this interpreter is to translate English words into French words and present you with a French letter that you can read. Any ideas as to where this analogy is headed?
French is equivalent to the native code of your computer while English is akin to generic Java bytecodes. The Java interpreter works very much like this human language interpreter because it takes Java bytecode and translates it into a form understood by different computing platforms.

The JVM is an interpreter for the bytecode form of the program and steps through one bytecode instruction at a time. However, you should also be aware that both the JVM and the user program are capable of spawning additional threads of execution, so that a user program may have many different functions running simultenously. The design of the JVM was built on many years of experience with earlier programming environments, namely C++.
We can think of the interpreter as having several different goals which are all intended to make life easier for the programmer:

1. Comprise a container for application code to run inside
2. Provide a secure execution environment as compared to C/C++
3. Take memory management out of the hands of developers
4. Provide a cross-platform execution environment

These objectives are often mentioned together when discussing the platform.
Unlike the Java compiler, the Java interpreter needs the class name (and not a file name) of the class containing the main method. That is, use periods as package separators, and do not use a file extension.
For example,

cd C:\java>
java homework.Tester

or

cd \cs1
java edu.sjsu.cs.homework.Tester