Jaron Omega wrote:
On Sun, 10 Apr 2005, Christopher Smith wrote:
It's just that C remains technically practical for any of the applications available today.
Agreed, and that's why C remains popular.
The Gimp is a C project... I suspect if you'd asked the Gimp guys why they didn't use Java they would have looked at you funny. They were C programmers, so they used C. That doesn't prove anything about Java anymore than Photoshop being written in C++ proves anything about C.To write PhotoShop entirely in ASM would just be suicide, but how much of Gimp is done in Java?
There are Gimp/Photoshop-like programs written in Java that work quite well. As an example JPhotoBrushPro works quite well. It's not as feature rich, but it's clear that's more a function of the resources invested in the project rather than something implicit in the language:
http://www.jphotobrushpro.com/
Sigh... another person who things difference between C and C++ is object oriented programming....This is the relation, most people still do not utilize the object oriented approach in project design, making the difference between C and C++ projects mere smoke and mirrors and a hand full of buzz-words.
So,I don't think anyone is arguing that you should use Java for performance reasons (actually, there is one exception to this, when I was at Sun we did recommend Java to the JPL for space missions, because it would simplify the problems they have with fragmented heaps). For most applications and most languages, the speed differences that occur because of which language you use tend to be trivial factors relative to the overall needs of a project. These days, choosing a language for speed is almost always silly, and even when it's not, you should prototype out your performance requirements in order to get a real idea of where the speed advantage is.
while it was true and people did say the same thing when C was taking
over ASM projects, I think today we have more validity in complaining
about the lack of advantages in speed and efficiency of Java replacing
C.
I wasn't thinking of IBM's JVM. I was thinking of runtimes designed for relatively short-lived programs. Something like gcj or some of the embedded (and oddly enough, interpreted) runtimes.efficiently. The "painfully slower" scenario applies to Sun's J2SE JDK
runtime, which as you can imagine, isn't terribly optimized for "hello
world" type programs. ;-)
Yes, most of the JVMs I deal with are Sun's own. I have put some interest
in IBMs JVM, but I didn't see any convincing reason to advocate it's use
over Sun's.
I think pretty much everyone misunderstood my post. I wasn't saying the JDK's for Linux suck. Indeed, Sun's JDK for Linux is built from the same source tree as the Windows and Solaris versions, so they are virtually the same. As a development platform for Java, Linux is as good as any other (and the one I use ;-).I have never seen a company say, "We would like this to runThe primary reason for this in my experience has been the poor support
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.
for Java on Linux.
With everything that I agree with in your post, here I have to say no. I think that Java on Linux is on par with Windows.
What I'm talking about is how well the platform integrates Java. On Windows or a Mac, I can double click on a jar file and start up a Java application. I *can* do that on Linux, but few distros are setup to do so. Few if any Linux applications and services provide Java API's (and those that do typically aren't ship with a Linux distro), so if you ship JNI code with your byte code, you might need to compile and deploy it at distribution time (yuck!). A lot of distros require you to setup the Java plugin manually, and many choose not to ship with Java at all. There is no standard way for Java application distributors to hook in to existing Java setups.
I'm hoping a lot of this might become rectified with the release of gcj4, which will finally give distros a way to ship an open source Java runtime that isn't completely pathetic.
Compare this to Java on OS X. Not only do they manage the packaging and stuff, but they provide Java interfaces to the entire Cocoa API. You can easily extend the operating system itself with tiny bits of Java code. Furthermore, OS X uses a shared Java runtime, so that running "hello world" doesn't incur the startup penalty it does on Linux.
--Chris
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
