On Sun, 2005-04-10 at 14:28 -0700, Jaron Omega wrote: > > On Sun, 10 Apr 2005, Paul G. Allen wrote: > > > A Java applet can provide a GUI as well, at a possible cost in speed. > > At a likely cost in speed. While Java is fine for most cases, it does > suffer incompatibility issues between versions of JVM and platforms
I am a java end-user not a java programmer, and I find what you say to be specifically true of the apps I've encountered, and it is quite noticeable in memory and CPU requirements, even by modern application standards. Often each major app requires its own enormous runtime environment. It could be the hammer-nail perspective, or it could just be that the class of apps I am being exposed to, but it seems that an inordinate amount of effort is spent in the minute details of the GUI of these programs, and much less in the logic and functionality. I would personally prefer something that worked, was simpler, and ran faster. I know I shouldn't be directing this at java as it's true of a lot of modern apps - in this age of microsoft, marketers are specifying program operation, and there is just so god damn much CODE being written all the time they just can't resist any new bell or whistle. Could it be it's both that the lack of snappyness is extra noticeable with java, and that java tends to be specified in these types of apps, that, well, gives it its reputation. > . > > I've written extensive Swing database front-ends in Java. I've abandoned > all Java/Swing code for more platform dependent code such as GTK. In > the beginning, the Java applet seems fast, seems competent. Indeed Sun > has made leaps and bounds with Java and it is "useable". But, it's > still very slow compared to native code. Very noticable. For instance, > I always write my own renderers for displaying tree data. During a > project writting a Java frontend to an LDAP database (directory rather) > the data would get parsed and scrolling the tree and doing massive > modifications to the tree forcing it to redraw and restructure the data > seemed slow. When you figure thousands and thousands of entries, it's > easy to chalk that off as, "well, considering what it's doing... duh!" > > I did not buy it. Rewrote the entire thing in C and GTK+ to include > custom GTK tree component renderers to mimic the Java feel, and I have > to say that without any doubt the GTK implementation was extremely fast > in doing all the same operations. > > There isn't one thing a Java project can do faster than native code; > noticably slower even on fast hardware when compared to native code. > Even a "hello, world" program is painfully slower. What makes Java > attractive, is several things but I suspect the chief reason is how > easy it is to write code in Java. I loved writing Swing applications > as I found Swing to be the easiest GUI API to deal with. Everything > in Java is pretty easy, and another benefit is when porting C/C++ code > to Java we often expose bugs that were overlooked in the C/C++ code base. > The third, and most common in my experience, attractive thing about Java > is that it runs on Windows. This is the main reason I refuse to do > any more Java development for personal projects or projects that have > feasible alternatives. Most of the time, when a company is porting > from C to Java, it's the simplest route from going from UNIX to > Windows. I have never seen a company say, "We would like this to run > on Linux, whats the best route? Port the Win32 code base to Java!" > I'm sure this has happened a few times, I never saw it it's usually > the other way round. Given that the java apps I've seen look like they were specified by a PHB, I wouldn't doubt it. > Omega -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
