| What you say might apply to a scripting language such as Tcl or bash..
Its
not true for Java. The way Java works is like this:
(1) programmer writes
source code.
(2) programmer (or in rare cases, some complex system) runs
Javac
to
compile the source code into Java bytecode (and related data
structures
e.g. constant pool) which is placed in .class files.
(3) a Java
VM is used to execute the .class files. It might do this with
an
"interpreter" (which is a bytecode interpreter, not a source-level interpreter
as you describe). Or it might use a "JIT compiler" which translates at
least
some of the bytecode into native machine code, and then executes
that native
code.
Some VMs use an interpreter to do all of their
execution, which is
the slowest but simplest and most-portable way to
write a VM. Some use JIT
compilation to execute everything. And some
use a hybrid strategy of using the
interpreter for rarely-executed code and
JITting the frequently-executed
code.
I once worked on a multi-platform Java VM that used a hybrid strategy
on
some
popular x86 platforms, but was also ported to many other platforms
where
the plain interpreter was used, because porting and maintaining the JIT
on
those platforms would be a huge amount of work.
(The amount of
programming effort it takes to create and maintain a good
JIT compiler for Java
is similar to the amount of programming effort it
takes to make the entire rest
of the VM. A bytecode interpreter, by
contrast, is much simpler and more
portable). [ Reply to This | Parent | # ]
| 
