These are some of the answers I got:
- Bytecodes are translated to native format on loading. Since server classes are only loaded infrequently, and thereafter kept in memory, it is not a big issue.Servers load slow, but run quick.
- Even you are right, OS seldom changes, it is designed for that purpose. If the conversion is made to native code for every developer, they will not know the advantage of JAVA, being "platform-independent". If you really want to make it to native code after considering in your case, you will not switch to another OS, and really want it to load faster, there are many tools available which helps you to convert JAVA source to native code.
- In many cases, develop on commodity WinTel boxes, deploy on expensive Sun servers. A Java source to native compiler can make certain optimizations, but it is basically guesswork as to which optimizations will help the most. Most compile-time optimizations are therefore a bit conservative. A JVM that runs interpreted bytecode has real runtime data to determine where aggressive to-native compiler optimizations will help the most. Only a few places in the program are turned to completely native code, but the native code can be aggressively optimized.
- Java does translate into machine code (which I assume you mean by "native format" - correct me if I'm mistaken). Furthermore, the beauty of running server code in a JVM is that the same product can run on different OSes. I routinely develop and test my Java projects, server, client and application, on Windows (XP these days), Linux and Solaris. Companies like IBM and Oracle, just to name two, are /awfully/ glad their server products are cross platform. The optimizations that Java (especially in server mode) can perform on your bytecode are generally superior to those performed statically at build time on compiled executables. Hey, isn't the object code in a compiled executable an intermediate format, too? Doesn't it get translated to "native format" also? Sun does not "force" you to keep your "codes" in bytecode. You are perfectly welcome to use .Net and C#. Of course then you are stuck using Windows servers, which are more expensive and less reliable than, say, Linux. Oh, and you are tied to a single vendor, Microsoft. Oh, and also all your support software, like the web servers and cluster-facets, have to come from that vendor. Hmm, maybe it's economics and the desire for functioning products that forces you to use Java. Short answer: Sun runs Java in a JVM because it works to do so, on technical grounds. Not as some sort of weird strong-arm tactic to oppress you. Maybe you should abandon the paranoid approach and just consider the technical and economic merits. The main tool that helps convert Java (not "JAVA") to native code is the JVM. It does a bang-up job and you don't have to go through a whole lot of fooferol with third-party products that will not improve the situation. How is load time even a consideration?
- Java is not especially suited to little, fast 'command line' based tools. Who would want to load a JVM (even a minimal or core one) just to do a directory listing, or delete a file? OTOH - it is best to start *learning* Java from the command line. So when the developer sees a 'hello world' application take 0.3 seconds it seems (because it is) 'slow', and gives the vague impression (to people who do not yet understand the strengths of the way Sun does it) that 'Java is slow'. The same applies (in some ways) to applets, with the added complication that some VM/browser combos. will cause a web page to 'freeze' while waiting for both the byte codes (and possibly media) to download, and the JVM to load and complete 'init()'! The places where Java is best and fastest, the server and long running desktop applications, are usually not 'seen' by end users and beginning developers.