Is Java compiled or interpreted?
Author
I am not much of a Java programmer (I prefer C++), but I am firmly of the opinion that Java is an interpreted language. However, other people disagree with that assesment saying it is compiled. Who is right?
I hope this is the right forum for this.
[edit] This thread probably should have gone in the Java Development Forum [/edit]
ProgrammingHobbit
[Edited by - ProgrammingHobbit on April 7, 2005 3:31:54 PM]
Java is compiled to bytecode, which was then traditionally interpreted. I hear that Java is JITed to native code these days, but there is much conflicting information about modern methods of Java execution.
AFAIK, the VM is written in the C, C++, and/or ASM (or even the OS' API). which would be compiled code. the java that is sent to the VM is interpreted code. that allows the write once, run anywhere effect. with JIT compilers though you can either bypass the interpreting the code and compile it in the cpu's machine code and run it. or the VM will take certain interpreted code parts and machine code compile them.
i'm pretty sure i'm wrong, but that's how i understand it.
i'm pretty sure i'm wrong, but that's how i understand it.
Considering that you have to use a program called the Java Compiler, so that you can compile your Java program, then the naive answer is that it's compiled.
Also, the definition I found on Wikipedia for "interpreted language" defines it as "a programming language whose programs may be executed from source form, by an interpreter". Since you cannot run Java programs from source form, it stands to reason that it's not an interpreted language.
Also, the definition I found on Wikipedia for "interpreted language" defines it as "a programming language whose programs may be executed from source form, by an interpreter". Since you cannot run Java programs from source form, it stands to reason that it's not an interpreted language.
Author
So its compiled (though not to native executable), then interpreted?
Does that sound right?
ProgrammingHobbit
Does that sound right?
ProgrammingHobbit
The question is really, are Java bytecodes compiled or interpreted?
The answer is typically both.
A modern JVM is capable of compiling (to native code) and interpreting bytecodes. How and where it does this is really up to the compiler.
Most of them are based on the "Hotspot" client or server VM. I'm not completely sure how these work, but I think it decides based on how often a method is run, whether it compiles or interprets it.
Compiling takes a significant amount of effort, so the VM doesn't just compile every method of every class by default - that would take too long (apparently). There are VMs however, which do compile every method of every class normally.
For example, with GJC you can compile every method of every class (it has an interpreter too though, but this is only used for code which hasn't been ahead-of-time compiled).
However, it seems that benchmarks have shown that GJC ahead-of-time compiled code performs considerably worse than hotspot just-in-time compiled code.
I don't know about commercial VMs though, they might be somewhat better than GJC.
Mark
The answer is typically both.
A modern JVM is capable of compiling (to native code) and interpreting bytecodes. How and where it does this is really up to the compiler.
Most of them are based on the "Hotspot" client or server VM. I'm not completely sure how these work, but I think it decides based on how often a method is run, whether it compiles or interprets it.
Compiling takes a significant amount of effort, so the VM doesn't just compile every method of every class by default - that would take too long (apparently). There are VMs however, which do compile every method of every class normally.
For example, with GJC you can compile every method of every class (it has an interpreter too though, but this is only used for code which hasn't been ahead-of-time compiled).
However, it seems that benchmarks have shown that GJC ahead-of-time compiled code performs considerably worse than hotspot just-in-time compiled code.
I don't know about commercial VMs though, they might be somewhat better than GJC.
Mark
Java is compiled into Java bytecode, but how it executes on your system is dependant on the Java Virtual Machine installed on the machine.
Some Java VM's interpret the bytecode, others compile the bytecode to native code and execute the native code. Still others do what is called "hotspot" compilation, where it will occasionally recompile certain areas of the code to more efficient native code based on how often the code is executed and how expensive the method is.
I hope that answers your question.
Some Java VM's interpret the bytecode, others compile the bytecode to native code and execute the native code. Still others do what is called "hotspot" compilation, where it will occasionally recompile certain areas of the code to more efficient native code based on how often the code is executed and how expensive the method is.
I hope that answers your question.
Quote:Original post by ProgrammingHobbit
So its compiled (though not to native executable), then interpreted?
Does that sound right?
ProgrammingHobbit
Actually yeah, that does sound right. I did more reading on Wikipedia and found this quote:
"Most so-called interpreted languages use an intermediate representation, which combines both compilation and interpretation. In this case, a compiler may output some form of bytecode, which is then executed by a bytecode interpreter. Examples include Python, Java, and Perl."
java is compiled to a byte code that is platform neutral (based on a hypothetical stack based system) much like .net and then, when run, it is JIT compiled to native code for the host machine, with optimizations performed on the most active parts (the "hot spots").
the first JIT compiler for java came out in 1996. the current hotspot compiler came out 6 years ago in 1999. java's been a compiled language for a long time. try and run a similar program in an interpreted language and you'll see the difference.
the only real things holding back java performance-wise are array bounds checking, increased precision required for functions like sin, cos, sqrt, etc, and the lack on an easy assembly inliner. but you get built in bounds checking, increased precision and theres always JINI, so its all about trade-offs.
the first JIT compiler for java came out in 1996. the current hotspot compiler came out 6 years ago in 1999. java's been a compiled language for a long time. try and run a similar program in an interpreted language and you'll see the difference.
the only real things holding back java performance-wise are array bounds checking, increased precision required for functions like sin, cos, sqrt, etc, and the lack on an easy assembly inliner. but you get built in bounds checking, increased precision and theres always JINI, so its all about trade-offs.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
