Unfortunately I've always found Java to be slow, regardless of the platform. If you think it's slow under OSX, try running a few Java applications under Windows NT! Java is meant to have been optimised under OSX by Apple, so much so that Sun may apply the same optimisations to other platforms. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
are you referring to graphical applets, or command-line applications?
I do find that applets with graphics like my <a href="http://homepage.mac.com/rogue27/ThreadedFractal/fractal.html"; target="_blank">fractal program</a> seem to be slower in X than they were in 9, at least in terms of screen redraws when dragging the mouse.
I think part of the problem just the slower 2D graphics in OS X that are caused by the more complex windowing system.
OS X automatically double buffers windows. This causes another speed issue, because many java applets are written double buffered so they won't flicker. Without adding double buffering to the java applet, it won't flicker on OS X, but will flicker on every other OS. Because of that, even I add double buffering to a lot of my java applets. Unfortunately, double buffering a java applet in an OS whose windows are already automatically double-buffered is effectively triple buffering the window which obviously is going to have some performance penalty.
I would hope there is some way to make it at least a little faster though. My <a href="http://mathlab.nmu.edu/classes-F02/CS446/rcarello/prog1/"; target="_blank">scaled graphics program</a> is sluggish on my powerbook but runs fine on these 700Mhz celerons around me in class.
I don't think it would be quadruple buffered, but I'm not sure.
There are two versions of the window in memory and then two versions of the java graphics in memory so there are 4 window buffers for the java applet in question, but what happens is that the java applet draws to the offscreen buffer, then the onscreen buffer copies the contents of the offscreen buffer, then OS X updates the java window in it's offscreen buffer and then the onscreen buffer copies the offscreen buffer over, then the window is composited with the rest of the the desktop and open windows.
Wow, a lot of steps involved. It's amazing that it runs at all!
Compare this with Mac OS 9 or Windows. Java draws to the offscreen buffer, the offscreen buffer is copied to the onscreen buffer which is then sent straight to the screen.
It may sound inefficient on OS X, but that is "the right way" to be doing this and in a few years when computers catch up to this advanced way of doing things, Windows and OS 9 will seem pretty sad and cheap.
OS X really does do a good job of doing these things fast when you consider how much more it's doing.
The thing is, it makes things easier for developers. You don't have to add code to double buffer your windows anymore, because the OS does it for you. However, in situations where you are doing cross-platform development, you do have to do the double buffering for everything that isn't OS X, so the double buffering code usually ends up being in software of that nature and it's just wasting clock cycles on OS X doing something that is already being done. Maybe when the rest of the world catches up, it might not be a problem.
<strong>I thought OSX java was suppose to be fast and unproblematic. The opposite is the case.
It's slow and suffers from so many screendraw problems, when will Apple fix this longstanding problem?</strong><hr></blockquote>
My astronomy applet that I link to in my signature ( <a href="http://www.skyviewcafe.com/"; target="_blank">http://www.skyviewcafe.com/</A>; ) is something that definitely suffers on OS 9 or OS 10 compared to running on Windows with either Sun's JVM or Microsoft's. It actually faster in OS 9 than it is on X.
(Most applets work well with Internet Explorer on the Mac now, but Mozilla and Netscape can be flaky. Be warned!)
One of the major problems for my Sky View Cafe applet is due to something another poster mentioned: misaligned doubles -- or at least something related to double-precision math. This applet is very math intensive. Even older PCs at 700 MHz are noticeably faster than my 800 MHz TiBook with this applet, and some benchmarks I've seen for double-precision math give a good indication why.
I think Apple can and will fix these problems, but they have a maddeningly slow update cycle. At this point, I'm afraid that I won't see any improvement until JDK 1.4 comes out, at the earliest. And then I'm afraid 1.4 will introduce new bugs, and those new bugs won't get fixed for another six months after the first release.
The current version of my applet uses AWT rather than Swing -- it was designed for broadest compatibility with old and new web browsers -- but AWT isn't well implemented in OS X. (That's not unique to Apple, by the way -- there are some awful AWT bugs I've seen in Windows and Linux lately too. I think Sun and Apple both are happy to give AWT bugs low, low priority as a way to "encourage" moving on to Swing.)
Why DO people use Java? Seriously? It's slow and unwieldy, it looks to me like it "sucks" sure enough. The only reason I am reluctant to diss it is because it's anti-M$...
cuz java suqs. write teh develpers, and tell them to learn a real lagnuage. one that uses a compiler.</strong><hr></blockquote>
Languages that are compiled result in faster applications, especially if the compiler produces true machine code, but by their very nature the applications are platform specific. One of the advantages of Java is that it's platform independent. Unfortunately, you can't have it both ways. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
Java is a good language because it is not platform dependant, it has a garbage collector which saves the programmer tons of developing time, more user friendly than C++, and it is pretty secure. The bad things about java is that on some machines, the Java Runtime Environment runs the byte code real slow, like the JRE on the macs , and java doesn't give as much power to the developer as C++ does. So there are pros and cons to the java language. Anyway, Apple really needs to get on the SDK 1.4 update... I am in need of using the assert command!!
Btw, I did some benchmark tests for java on my mac vs. some crap pc. And the crap pc(400Mhz P3, win 98) ran the my code in 600ms while the mac (iBook 700Mhz G3, OS 10.2.1) ran it in 1800ms!!! Apple really needs to boost java performance!!
Languages that are compiled result in faster applications, especially if the compiler produces true machine code, but by their very nature the applications are platform specific. One of the advantages of Java is that it's platform independent. Unfortunately, you can't have it both ways. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
have you heard of the free software foundation (www.gnu.org)? almost everything they make is in c/c++, and compiles cross platform. including their grrrreat compiler (gcc). oss is the waive of the future --today!
have you heard of the free software foundation (www.gnu.org)? almost everything they make is in c/c++, and compiles cross platform. including their grrrreat compiler (gcc). oss is the waive of the future --today!</strong><hr></blockquote>
It sounds very interesting. I'm not sure whether you're saying the same source code can be compiled for different platforms, producing a different executable on each platform, or whether the same executable can run on different platforms. <img src="confused.gif" border="0">
It sounds very interesting. I'm not sure whether you're saying the same source code can be compiled for different platforms, producing a different executable on each platform, or whether the same executable can run on different platforms. </strong><hr></blockquote>
Umm, he means that the same source code can be compiled for different platforms. Obviously you have never strayed away from a GUI or you would be familiar with this and the following sequence of commands:
./configure
make
make install
which is usually all it takes to compile gnu or other open source software on any platform (unix that is - OSX included).
Umm, he means that the same source code can be compiled for different platforms. Obviously you have never strayed away from a GUI or you would be familiar with this and the following sequence of commands:
./configure
make
make install
which is usually all it takes to compile gnu or other open source software on any platform (unix that is - OSX included).</strong><hr></blockquote>
So you're suggesting the average user, and a Mac user at that, should download source code, enter a command line interface and compile their own applications? Clearly you have never worked in a department providing support for Macintosh users.
compiled java applets are platform independent. Compiled java applications are not.
cross-platform C or C++ code typically won't have any graphics or gui stuff, because that stuff is platform specific.
java graphics and gui stuff are not platform specific, so you can compile java applications that use gui and graphics elements for multiple platforms without having to change any code.
java is useful because of it's cross platform nature and because it does some things, like garbage collection, automatically.
Comments
I do find that applets with graphics like my <a href="http://homepage.mac.com/rogue27/ThreadedFractal/fractal.html"; target="_blank">fractal program</a> seem to be slower in X than they were in 9, at least in terms of screen redraws when dragging the mouse.
I think part of the problem just the slower 2D graphics in OS X that are caused by the more complex windowing system.
OS X automatically double buffers windows. This causes another speed issue, because many java applets are written double buffered so they won't flicker. Without adding double buffering to the java applet, it won't flicker on OS X, but will flicker on every other OS. Because of that, even I add double buffering to a lot of my java applets. Unfortunately, double buffering a java applet in an OS whose windows are already automatically double-buffered is effectively triple buffering the window which obviously is going to have some performance penalty.
I would hope there is some way to make it at least a little faster though. My <a href="http://mathlab.nmu.edu/classes-F02/CS446/rcarello/prog1/"; target="_blank">scaled graphics program</a> is sluggish on my powerbook but runs fine on these 700Mhz celerons around me in class.
*sigh*
[ 09-19-2002: Message edited by: rogue27 ]</p>
There are two versions of the window in memory and then two versions of the java graphics in memory so there are 4 window buffers for the java applet in question, but what happens is that the java applet draws to the offscreen buffer, then the onscreen buffer copies the contents of the offscreen buffer, then OS X updates the java window in it's offscreen buffer and then the onscreen buffer copies the offscreen buffer over, then the window is composited with the rest of the the desktop and open windows.
Wow, a lot of steps involved. It's amazing that it runs at all!
Compare this with Mac OS 9 or Windows. Java draws to the offscreen buffer, the offscreen buffer is copied to the onscreen buffer which is then sent straight to the screen.
It may sound inefficient on OS X, but that is "the right way" to be doing this and in a few years when computers catch up to this advanced way of doing things, Windows and OS 9 will seem pretty sad and cheap.
OS X really does do a good job of doing these things fast when you consider how much more it's doing.
The thing is, it makes things easier for developers. You don't have to add code to double buffer your windows anymore, because the OS does it for you. However, in situations where you are doing cross-platform development, you do have to do the double buffering for everything that isn't OS X, so the double buffering code usually ends up being in software of that nature and it's just wasting clock cycles on OS X doing something that is already being done. Maybe when the rest of the world catches up, it might not be a problem.
[ 09-19-2002: Message edited by: Altivec_2.0 ]</p>
<strong>I thought OSX java was suppose to be fast and unproblematic. The opposite is the case.
It's slow and suffers from so many screendraw problems, when will Apple fix this longstanding problem?</strong><hr></blockquote>
My astronomy applet that I link to in my signature ( <a href="http://www.skyviewcafe.com/"; target="_blank">http://www.skyviewcafe.com/</A>; ) is something that definitely suffers on OS 9 or OS 10 compared to running on Windows with either Sun's JVM or Microsoft's. It actually faster in OS 9 than it is on X.
(Most applets work well with Internet Explorer on the Mac now, but Mozilla and Netscape can be flaky. Be warned!)
One of the major problems for my Sky View Cafe applet is due to something another poster mentioned: misaligned doubles -- or at least something related to double-precision math. This applet is very math intensive. Even older PCs at 700 MHz are noticeably faster than my 800 MHz TiBook with this applet, and some benchmarks I've seen for double-precision math give a good indication why.
I think Apple can and will fix these problems, but they have a maddeningly slow update cycle. At this point, I'm afraid that I won't see any improvement until JDK 1.4 comes out, at the earliest. And then I'm afraid 1.4 will introduce new bugs, and those new bugs won't get fixed for another six months after the first release.
The current version of my applet uses AWT rather than Swing -- it was designed for broadest compatibility with old and new web browsers -- but AWT isn't well implemented in OS X. (That's not unique to Apple, by the way -- there are some awful AWT bugs I've seen in Windows and Linux lately too. I think Sun and Apple both are happy to give AWT bugs low, low priority as a way to "encourage" moving on to Swing.)
One thing I can say in favor of Java on the Mac: I sure can look nice!
cuz java suqs. write teh develpers, and tell them to learn a real lagnuage. one that uses a compiler.
Yet with my NEW dual 867 G4, I'm lucky if it loads, and then if it works at all.
There is something screwy about the default install of Apple's implementation of Java, I think. Otherwise, they simply suck at it.
<strong>
cuz java suqs. write teh develpers, and tell them to learn a real lagnuage. one that uses a compiler.</strong><hr></blockquote>
Languages that are compiled result in faster applications, especially if the compiler produces true machine code, but by their very nature the applications are platform specific. One of the advantages of Java is that it's platform independent. Unfortunately, you can't have it both ways. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
[ 09-20-2002: Message edited by: RodUK ]</p>
Btw, I did some benchmark tests for java on my mac vs. some crap pc. And the crap pc(400Mhz P3, win 98) ran the my code in 600ms while the mac (iBook 700Mhz G3, OS 10.2.1) ran it in 1800ms!!! Apple really needs to boost java performance!!
(somebody said something about tweaking your code to fix this)
<strong>
Languages that are compiled result in faster applications, especially if the compiler produces true machine code, but by their very nature the applications are platform specific. One of the advantages of Java is that it's platform independent. Unfortunately, you can't have it both ways. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
[ 09-20-2002: Message edited by: RodUK ]</strong><hr></blockquote>
have you heard of the free software foundation (www.gnu.org)? almost everything they make is in c/c++, and compiles cross platform. including their grrrreat compiler (gcc). oss is the waive of the future --today!
<strong>
have you heard of the free software foundation (www.gnu.org)? almost everything they make is in c/c++, and compiles cross platform. including their grrrreat compiler (gcc). oss is the waive of the future --today!</strong><hr></blockquote>
It sounds very interesting. I'm not sure whether you're saying the same source code can be compiled for different platforms, producing a different executable on each platform, or whether the same executable can run on different platforms. <img src="confused.gif" border="0">
<strong>
It sounds very interesting. I'm not sure whether you're saying the same source code can be compiled for different platforms, producing a different executable on each platform, or whether the same executable can run on different platforms.
Umm, he means that the same source code can be compiled for different platforms. Obviously you have never strayed away from a GUI or you would be familiar with this and the following sequence of commands:
./configure
make
make install
which is usually all it takes to compile gnu or other open source software on any platform (unix that is - OSX included).
<strong>
Umm, he means that the same source code can be compiled for different platforms. Obviously you have never strayed away from a GUI or you would be familiar with this and the following sequence of commands:
./configure
make
make install
which is usually all it takes to compile gnu or other open source software on any platform (unix that is - OSX included).</strong><hr></blockquote>
So you're suggesting the average user, and a Mac user at that, should download source code, enter a command line interface and compile their own applications? Clearly you have never worked in a department providing support for Macintosh users.
cross-platform C or C++ code typically won't have any graphics or gui stuff, because that stuff is platform specific.
java graphics and gui stuff are not platform specific, so you can compile java applications that use gui and graphics elements for multiple platforms without having to change any code.
java is useful because of it's cross platform nature and because it does some things, like garbage collection, automatically.