A fundamental question about bytecode and nativecode

[cat_dog_ass]

At the server end, why should Sun force us to keep our codes in
bytecode (class) format? Why not allow us the translate code into
native format so that it servers the clients a lot quicker? I'm sure
this is technically possible. Then what the allure of bytecode. People
don't change their server end operating systems often. Then the OS
neutrality of bytecode should hardly be of any relevance today.

 

[Andrew Thompson]

At the server end, why should Sun force us to keep our codes in
bytecode (class) format? Why not allow us the translate code into
native format so that it servers the clients a lot quicker?

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.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Matej Cepl]

At the server end, why should Sun force us to keep our codes in
bytecode (class) format? Why not allow us the translate code into
native format so that it servers the clients a lot quicker? I'm sure
this is technically possible. Then what the allure of bytecode. People
don't change their server end operating systems often. Then the OS
neutrality of bytecode should hardly be of any relevance today.

http://gcc.gnu.org/java/

 

[Harry]

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. (I agree to Andrew, it still run fast for
bytecode)

This is one of the examples:
http://gcc.gnu.org/java/

Harry

 

[Adam Maass]

At the server end, why should Sun force us to keep our codes in
bytecode (class) format? Why not allow us the translate code into
native format so that it servers the clients a lot quicker? I'm sure
this is technically possible. Then what the allure of bytecode. People
don't change their server end operating systems often. Then the OS
neutrality of bytecode should hardly be of any relevance today.

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
basicly 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 aggresive
to-native compiler optimzations 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.

 

[Lew]

http://gcc.gnu.org/java/

I have never found Gnu "Java" usable.

It's probably just me. But it's always a couple of versions old and misses a
lot of what I use in Java. Plus it doesn't seem to integrate with anything.

Just give me Sun or IBM JVMs for server or desktop.


As Andrew pointed out, 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.

 

[Lew]

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".

Very good point, which would have been better made inline rather than top-posted.

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. (I agree to Andrew, it still run fast for
bytecode)

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?

This is one of the examples:
http://gcc.gnu.org/java/

Yecch.

 

[Patricia Shanahan]

In many cases, develop on commodity WinTel boxes, deploy on expensive
Sun servers.

Or my case, develop and do small runs on a WinTel workstation, do big
runs on a Linux grid.

Patricia

 

[Andrew Thompson]

Lew wrote:
..

How is load time even a consideration?

You've hit upon one of my 'pet beefs'. 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 bytecodess
(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.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Eric Sosman]

Lew wrote:
.

You've hit upon one of my 'pet beefs'. 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?

Agreed! But it's my impression that Java startup has
improved quite a bit with succeeding versions. Not so long
ago I did a two-generation upgrade from 1.4 to 1.6, and the
time-to-first-rumblings seems to have shortened a good deal.
(No actual measurements, just an informal sense of immediacy.)

In the 1.2 days, of course, "Initializing Java ..." was
a cue to go get coffee.

 

[blmblm]

[ snip ]

Hey, isn't the object code in a compiled executable an intermediate format,
too? Doesn't it get translated to "native format" also?

How so? As I understand it, object code is "machine language" --
binary data that can be directly executed by the processor. What
am I not getting here?

[ snip ]

 

[Mark Thornton]

[ snip ]

Hey, isn't the object code in a compiled executable an intermediate format,
too? Doesn't it get translated to "native format" also?

How so? As I understand it, object code is "machine language" --
binary data that can be directly executed by the processor. What
am I not getting here?

[ snip ]

Most modern processors perform yet another translation stage from say
x86 code into some internal form which is actually executed.

 

[blmblm]

[ snip ]

Hey, isn't the object code in a compiled executable an intermediate format,
too? Doesn't it get translated to "native format" also?

How so? As I understand it, object code is "machine language" --
binary data that can be directly executed by the processor. What
am I not getting here?

[ snip ]

Most modern processors perform yet another translation stage from say
x86 code into some internal form which is actually executed.

Aha. How embarrassing that I was somehow blissfully unaware of
this .... Well, as they say in another newsgroup I follow: You
learn stuff here. Thanks.

 

[Ian Wilson]

[ snip ]

Hey, isn't the object code in a compiled executable an intermediate
format, too? Doesn't it get translated to "native format" also?

How so? As I understand it, object code is "machine language" --
binary data that can be directly executed by the processor. What
am I not getting here?

[ snip ]

Most modern processors perform yet another translation stage from say
x86 code into some internal form which is actually executed.

http://en.wikipedia.org/wiki/Microcode

 

[Andy Dingley]

You've hit upon one of my 'pet beefs'. Java is not especially suited
to little, fast 'command line' based tools.

Compared to interpreted shell? Shell that uses embedded sed and
scratchfiles to process strings?

My desktop box is 2GB of Windows XP, running a shedload of scripts in
shell, Python and Java. Of all the things that exist solely to put a
crimp in my day, JVM classload times aren't anywhere near the biggest.

XP taking 20 minutes to delete files probably _is_ the biggest. OK, so
there's a lot of files in some of those directories and TortoiseSVN is
probably implicated too. But if I'm going to start pointing the finger
of bloatware blame at anything, it'll be the flakey stability-
blancmange that is Windows Exploder, long before it's my JVM.

 

[blmblm]

[ snip ]

Hey, isn't the object code in a compiled executable an intermediate
format, too? Doesn't it get translated to "native format" also?


How so? As I understand it, object code is "machine language" --
binary data that can be directly executed by the processor. What
am I not getting here?

[ snip ]

Most modern processors perform yet another translation stage from say
x86 code into some internal form which is actually executed.

http://en.wikipedia.org/wiki/Microcode

Oh, *microcode* .... Yeah, okay, I guess then one could think
of object code as being an intermediate format, though the
Wikipedia article referenced above seems to me to indicate
that for x86 the "translation" to "native format" happens on
the fly and in hardware.

Terminology quibbles, maybe.

 

[Mark Thornton]

Oh, *microcode* .... Yeah, okay, I guess then one could think
of object code as being an intermediate format, though the
Wikipedia article referenced above seems to me to indicate
that for x86 the "translation" to "native format" happens on
the fly and in hardware.

There are number of different x86 implementations. Intel has several
several, then there are AMD, TransMeta, VIA and others.

 

[Mike Schilling]

In many cases, develop on commodity WinTel boxes, deploy on expensive
Sun servers.

In my case, develop on a Wintel box, test on several Wintel OSes, various
Linuxes, Solaris (both Intel and Sparc), and whatever else the silly
customers want to run on. It's not a huge convenience that the same
"executable" format works on all of them (if we had to build multiple
executables as we did in C and C++ days, that could be done), but it's not
wholly insignificant either.

 

[Lew]

In my case, develop on a Wintel box, test on several Wintel OSes, various
Linuxes, Solaris (both Intel and Sparc), and whatever else the silly
customers want to run on. It's not a huge convenience that the same
"executable" format works on all of them (if we had to build multiple
executables as we did in C and C++ days, that could be done), but it's not
wholly insignificant either.

I no longer see the original posts on this thread, but I believe other posters
have pointed out the error in the OP's assumption that deploying in native
code would result in faster execution than the JVM can achieve on bytecode.

The premise that if you "translate code into native format [outside the JVM]
.... it serve the clients a lot quicker" is flawed. It might actually run
slower than the current generation of JVMs.

 

[Guest]

The premise that if you "translate code into native format [outside the
JVM] ... it serve the clients a lot quicker" is flawed. It might
actually run slower than the current generation of JVMs.

Yep.

The only areas where I see native having an advantages is
startup time and memory footprint for small apps.

Arne