X
Tech

Defending Java against Paul Murphy

Paul Murphy recently wrote a piece where he made the worst insult a Unix person can make about any technology used in Unix environments. He called Java "Windows on Unix.
Written by John Carroll, Contributor

Paul Murphy recently wrote a piece where he made the worst insult a Unix person can make about any technology used in Unix environments. He called Java "Windows on Unix." Next up, Paul Murphy will call Dallas residents New Yorkers in cowboy hats, and accuse Hillary Clinton of being a fan of William F. Buckley.

But hey, every interest group has an enemy, and for old-school Unix types, hatred of Microsoft is knitted into the fabric of their cardigan sweaters. What moved me to respond, however, was what I consider to be an inaccurate portrayal of the Java environment. Granted, I'm a Microsoft employee and think .NET is the best thing since sliced bread. I am also, however, a programmer who spent seven years on and off doing various kinds of Java work.

The core problem in Murphy's piece is that he seems to have bought into Sun's former marketing, believing that Java is merely a means by which to ensure a program can be "written once and run anywhere." Yes, James Gosling and his team of developers at Sun originally designed Java (then named "Oak") as a platform to run within Set-Top Boxes with an eye towards making it easy to write one program that executes on multiple types of hardware. And yes, Java has found itself into other devices where cross-platform support is important, such as cell phones, and even Blu-ray players.

Sun did make a pitch to turn the Java runtime into a common layer targeted at desktop computers that would make it easy to run an application on any Java-supporting platform using one common set of "bytecodes" (the object oriented assembly language, of sorts, that defines the instructions in a Java application...not that most people would have to generate that code themselves, as that is what a Java compiler is for). That effort, however, never really went very far.

Likewise, Java development targeted at cell phones is growing. That, however, is a relatively late arrival in the history of the Java runtime, and is hardly the thing that has brought Java "back from the brink."

Java's bread and butter from it earliest days - in spite of the original intent of its designer - has always been server-side development.

Murphy, in other words, has the order of events backwards. People didn't start on the desktop with Java and fall back to the server as the desktop platform failed to gain traction. Server side development has always been an important part of the Java development story.

Murphy thinks this was some kind of accident, a result of stubborn developers who had spent lots of time learning Java skills targeted at client-side development showing a reluctance to ditch those hard-earned abilities (though the fact that Sun, a company favored by Murphy, had such a strong server product line surely had something to do with it). I think that's nonsense, not because I have a theory about what might motivate other people, but because I know what attracted me to Java in the first place.

What attracted me was the wonders of a managed runtime. Managed runtimes give you lots of important features that solve a lot of programming issues. They give you garbage collection, built-in security (no more buffer underruns, as an example), strong error handling in the form of exceptions built into the base framework, built-in tools for communication between machines at an object level, strong object orientation, reflection...the list goes on. Managed runtimes are the way MODERN programs should be built.

Are Java programs as efficient as native binaries? Of course not. But then again, C++ code isn't as efficient as C, and C isn't as efficient as assembly language. In this blogger's humble opinion, anyone who suggests that modern programs should be written in assembly language in order to achieve maximum performance should be locked in a room and forced to make sense of that stream of fluctuating characters that supposedly "meant something" in The Matrix.

Paul seems of the opinion that C is the epitome of elegant programming. I strongly beg to differ. Quite frankly, writing a modern program in C is about as sensible as writing a book in Old English. It's antiquated, it has poor support for object orientation (unless you think building your own vtables counts as object-oriented support), and it is not far off from insisting that everyone write code in assembly language.

Likewise, where does Murphy get the idea that C has fewer, more elegant libraries than Java? Both languages, from a syntax standpoint, are fairly terse. You could no more write an entire program in C using only C-language keywords than you could in Java.

That means you need libraries, which are the essential extensibility points in ALL C-family languages. Libraries are libraries are libraries are libraries. You have to know what they are, and how to call them. In other words, you have to memorize them (though modern development environments have something called intellisense that reduces the need to memorize everything). There are LOTS of C libraries in existence, a result of the language's long lifespan in the computer industry. Further, given the lack of object orientation in C, you end up having lots of calls with a bazillion arguments, adding to one's memorization woes.

I have my differences with Java, and these days, have little desire to program in the language. That is not, however, because I have realized that most code now runs on the server and I can do everything in C. Rather, I have found what I consider to be a better managed runtime (and feel free to disagree; my current preferences aren't the subject of this post).

Managed runtimes are the future. If anyone can be accused of a reluctance to put down their old tools and move to a better-suited technology, it is the old C-wizards who jealously insist on continuing to use the languages of a bygone era.

Editorial standards