This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
The JIT compiler compiles code "on the fly". I don't know What r u getting from the phrase "on the fly". The JIT compiler never facilitate u to make the exe of java code rather it itself generates a byte code that is always interpreted by a JVM only. So, according to me "on the fly" does not mean that u can make the exe of the java code and hence does not need Java Virtual Machine( JVM ), but it means that the code is generated for use on any machine as it is a byte code.
sry u r wrng .. cough, cough Excuse me, I had something stuck in my throat. As I was saying, sorry, but that's wrong. A JIT compiler compiles (some) Java bytecodes into hardware-specific native code at runtime. The resulting native code snippets still need the context of the JVM in which to run, but the process eliminates the overhead of interpreting the bytecodes.
Sun's JVMs use a sort of "smart" JIT called HotSpot that works hard to translate only performance-critical sections of your code into native code, and optimize those bits heavily using runtime profiling data as a guide. The traditional sort of JIT that translates all the bytecode has fallen out of favor, largely because JVMs are so fast now that the overhead of JIT compilation outweighs the overhead of bytecode interpretation.
In contrast to a JIT ("just-in-time") compiler, there also exist AOT ("ahead-of-time") compilers, which translate an entire program into native code and turn it into a self-contained EXE file. None of these compilers produce results which are significantly better than what HotSpot does.
Well-written Java code is generally within a factor of two in performance of equivalent C++ code. Note that I say "within a factor of two" and not "half as fast"; sometimes, it's the C++ code that's slower (particularly with certain C++ compilers.)
I think Bhushan was trying to explain that a JIT compiler does not create an executable file, as you described, Ernest. However, as you said, it doesn't create byte code either, it takes the byte code that was previously compiled (with javac, for instance), and compiles it to native machine code. (Basically that's repeating what Ernest said. I just like to summarize some times.)