[absmiths]

Has anybody noticed this FAQ on Apple's dev site:

Q: What is the expected timeline for GCC 3.x to be the preferred compiler for OS X? In particular, the java to native code and updated STL.

A: We have various people looking at the new features of GCC 3 right now. We can't give dates, but switching to GCC 3 is one of our three top priorities (better compile speed and better output code being the other two).

That's cool, if they can make it happen. That would greatly increase the feasability of doing Java Cocoa programs.

[Millennium]

I don't actually do much Java myself, but I know enough to know that most well-programmed Java apps aren't really noticeably slower than their native counterparts, except in launch time (where you have to launch the JVM). For a good example of a fast Java app, look at CrushFTP.

There's one big exception to this, of course: programs which have to do lots of CPU-intensive computations. There are three types of programs that fall under this category. First off is intensive number-crunchers, like RC5, SETI, Mathematica, most 3D renderers, and so on. For these, you need native code for the heavy lifting, though Java will work fine for the interface. Some programs that ordinarily don't have to do a great deal of math but may end up having to, such as Excel, also fall here. However, most programs of this nature already do their heavy work in assembly, and wrap higher-level code around it for less intensive tasks.

The second is certain types of games, notably 3D-intensive ones. Here, Java's basically a no-go at this point, and probably will be for quite some time. But again, the most critical parts tend to be hand-optimized in assembler.

The last is multimedia. But this is a moot point as far as Cocoa/Java is concerned, since QuickTime and company are already native.

So really, Java-to-native doesn't mean a whole heck of a lot. You get a bit of a boost at launch time, but other than that, I'm not sure how noticeable the difference would be. Still, it's a cool thing to have, at any rate.

[sadie]

The way most JVMs work nowadays, with Just In Time compiling and similar schit, Java code basically does run native anyway. Even if you do compile it into fully native code, it's never going to be quite as safe because it just has more safety checks to do all the time.

For example, if you try to execute:
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>x = <font color = blue>2</font> / <font color = blue>0</font>;</font>[/code]
you'll get a DivideByZeroException (or somesuch). And that has to be generated by the system checking every single divide operation. So however agressively you optomize it, things in there slow it down.

(edit: ubb fixed)

[ 12-13-2001: Message edited by: sadie ]

[absmiths]

Originally posted by Millennium:
<STRONG>There's one big exception to this, of course: programs which have to do lots of CPU-intensive computations.</STRONG>

I agree with you mostly. I did a research experiment at college a while back to determine if Java was a suitable replacement for FORTRAN or C in numerical applications. The answer was no, but not by a huge margin. That was back in 97, using JDK 1.1. I found this page the other day and they claim their numerical library is only 2.5 times slower than a library of hand-tuned assembler written by Intel:
Colt

That said, the things I would look for native compilation to improve are issues like packaging - you could have a command line tool distributed as a single executable (NOT a package); Commands that call native code a lot could have highly optimised JNI calls - which could drastically increase the performance of GUI operations.

80's-style arcade games work really well in Java - and even moderate OpenGL stuff is nice too if you have OpenGL native rendering support - but not much more than that. (Unless you want to release a game and tell your users that in about 10 years it will really fly!)

[theolein]

Originally posted by sadie:
<STRONG>The way most JVMs work nowadays, with Just In Time compiling and similar schit, Java code basically does run native anyway. Even if you do compile it into fully native code, it's never going to be quite as safe because it just has more safety checks to do all the time.

For example, if you try to execute:
&lt;BLOCKQUOTE&gt;&lt;font size="1"face="Geneva, Verdana, Arial"&gt;code:&lt;/font&gt;&lt;HR&gt;&lt;pre&gt;& amp;lt;font size=1 face=courier&gt;x = &lt;font color = blue&gt;2&lt;/font&gt; / &lt;font color = blue&gt;0&lt;/font&gt;;&lt;/font&gt;&lt;/pre&gt;&lt;HR&gt;&lt;/BLOCKQUOTE&gt;
you'll get a DivideByZeroException (or somesuch). And that has to be generated by the system checking every single divide operation. So however agressively you optomize it, things in there slow it down.

(edit: ubb fixed)

[ 12-13-2001: Message edited by: sadie ]</STRONG>

If you try to compile the code above you will get a compile time error. It is possible to get around this by substituting a variable in place of zero, but that has nothing to do with the byte code verifier which verifies the code when a class is loaded into memory by the VM.