OSNews

Well, I have to say this essay is mostly B.S. designed to support someone who obviously has an unreasonabe bias towards C (unreasonable that he is willing to use B.S. to support it)

First, the portability issue. You do NOT rely on Sun's whims. In case the author hasn't noticed, there are plenty of other vendors that make implementations of Java for tons of platforms--including three open source projects in the works to produce open source Java implementations. Also, on the portability issue, I can pretty much guarantee the author that for a complex application, I am going to have far fewer portability issues writing it in Java than in C.

"You cannot effectively duplicate a struct containing other structs in Java or in Perl as you can in C."

Why not? The only difference is you have to use a class.

"You cannot work with interrupts, DMAs, and other hardware elements"

...But what happenend to that portability he was just touting in your last paragraph?

"Many problem domains call for ANSI C"

No, they don't. Only very low level problem domains call for ANSI C, and domains where squeezing the absolute maxiumum possible performance out of a system is critical. The rest of the time, it is not worth the 5 to 10 fold increase in development time and the even larger increase in debugging time thanks to stale pointers, memory leaks, and other memory issues which are the single biggest cause of persistant bugs in production software.

"There's no fork() in Java, and not many other UNIX system calls."

And there are no threads in ANSI C or the C standard library. And threads are much more useful and lighter weight for most purposes. Certainly you can use third party libraries to add threads to C, but that creates lot of portability headaches. And I can also use JNI libraries to get fork() in Java... But since he brought up fork() and other system calls... So much for that portability he was touting earlier.

"Many real-time applications (i.e: applications that should respond to events within a given time) must be written in a low-level language for that reason."

Really? Tell that to Boeing, who was showing off a completely automated reconnaissance aircraft at JavaOne that requires no human pilot and no human intervention, and can automatically update it's flight plan based on what its cameras and scensors see in real-time battle conditions. It's "pilot" is written in Java. Or maybe tell it NASA, who decided that Java was suitable for writing the Mars Rover software.

The abililty to respond to events in a given time is critical yes, but that's what Real Time Java is for. But there is something else that is usually critical in these real time applications as well, and that is reliability and robust fault recovery--areas where Java shines but C is severely lacking because of its lousy error handling facilities and lax stance towards ensuring that potential errors have been dealt with.

"Now, how do we do it in Java? In Java every reference to a structure or an array is allocated and manipulated individually. We cannot have them chained one by one in memory."

I'm not following his logic. This sounds to be nothing more than an array of pointers to structs, or what in Java, would be an array of objects. In reality of course, in Java, the array does not contain the objects themselves, but only pointers to the locations of those objects. So I'm not sure what he means when he says the references can only be manipulated individualally, and cannot be chained in memory. That's simply not true.

Overall, this essay is mostly B.S. from someone who is either very uninformed about Java, or who is intentionally putting a huge spin on things to support C.

For a much more informative discussion of why C is usually not the right choice to start a new application today, and of the few times where it is, see Art of UNIX Programming, by Eric Raymond, which is available online.