Skip to main content

A question is answered

What's the great urgency in translating Java source code into byte code instead of machine code? OS independence hardly seems of any relevance today since people seldom change it. Then why...?

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.

Comments

Popular posts from this blog

The year that was

I'm wearing a rather striking shirt, one that makes me feel like a clown fooling around in a graveyard. Roving eyes latch on to me and make me too conscious of myself. Checkered in red, grey, black and maroon, I've excused myself into donning it and looking silly for two reasons. It's Friday and…more importantly, the last working day of the year. Tailored half-a-year back, I never had the courage to wear it, not until today. It's that time of the year when it's time to reflect on the events that transpired. Last year ended on the worst possible note. Dad had expired and I was numb with shock. The repercussions rippled halfway thought this year. Things were so abysmal initially that I had lost the will to live. Acrid in everything I did, I was immensely angered by time phlegmatically flowing through its cadence. It was as if Dad meant nothing to anybody. What right did people have to live the way they always had when Dad was no more? Why was much of the world still…

Searching for someone

I remember hearing a song by someone in a movie with Charlize Theron and Keanu Reeves as the protagonists. Charlize is a free-spirited girl who is terminally-ill while Keanu is an ambitious lawyer who is captivated by Charlize's ways. The most memorable thing about the movie, though, was the song. I tried to ferret some information about the song yesterday, and its unknown singer.


Searched for Charlize Theron via Wikipedia. Browsed through her filmography and zeroed in on Sweet November (2001), which rung a bell. I didn't remember the name of the movie and hoped this was the one.Clicked on Sweet November. The plot confirmed my doubt! This was indeed the movie I was looking for.Searched for Sweet November via Yahoo! Music. Managed to find the original motion picture soundtrack.Clicked on the link. Found the list of tracks. There were 13. Now which one was I looking for?Visited Amazon and searched for Sweet November. Gotcha! The list of tracks, however, gave no information about …