Karlos wrote:
@Smithy
I think you misunderstood me. Basically, I am asking, who would use a static compiler for their java application deployment if a JIT is able to deliver similar performance without ever having to recompile the application should the hardware get updated?
When you say static compiler, do you mean compile to machine code rather than byte code? I still don't think this has any impact on GCJ. If you use GCJ rather than Sun's "javac" tool, then it means you are probably an open-source, er, "believer", shall we say? In which case, you'll probably also be using one of the many open source JIT JVMs anyway.
The main reasons for using a compiler are to get speed on systems where a JIT is not available (for whatever reason) or for protecting your code (bytecode is pretty easy to decompile).
Compiling to binary, like you say, might be mainly to protect your source code. But you won't be doing it because you don't have an open source JIT JVM (there are plenty of them) in which case an open source Sun JIT VM isn't going to help you.
The latter isnt much of a problem for a server application however, so the main reason for using a compiler would be the former. If you were running a server, would you prefer to just update the JVM itself whenver you needed to upgrade, or recompile all your code?
If I was using Java on the server then I'd be using J2EE, of which every implementation has JIT (even the open source JBoss has JIT - you'd have to look hard to find a server JVM without JIT). There is no prospect of using any native code with J2EE. But then, if I was
really interested in performance, and I mean really, because JIT Java is fast - native will not improve your execution speeds much, then I'd not use Java in the first place!