Standing in the Field @ Valley Forge

Standing in the Field

Notes from SJS Application Server Field Engineering

« Previous day (Aug 29, 2004) | Main | Next day (Aug 31, 2004) »
Monday August 30, 2004
Referrer Spam

I'm having trouble filtering referrer spam, so I've had to remove the referrer sites. At least temporarily. In the meantime, if you want to know who is linking here you can find similar information at Technorati

(2004-08-30 22:43:30.0) Permalink

Comparing Perl and Java

First of all, sorry for the delay in posts. I spent August moving my residence. In addition to closing on a house, cleaning up the old apartment, changing my address a billion places, and moving all of my stuff I also had a busy month at work. It never rains but it pours, so they say. Not to mention that I've been without internet access at home for several weeks. (That was driving me crazy very rapidly.) Hopefully I'll be able to get back to regular posts now that things have calmed down.

This post is about a pet peeve of mine. Every so often, when I assert that Java's licensing and TCKs are what keeps Java cross-platform I will get a heckler that says "Yeah, because Perl is so incompatible with its open source license."

This really drives me crazy because I had a lot of personal experience with Perl incompatibility. In a former life I had to port a collection of perl scripts from Solaris to Windows and it was a nightmare. Most of scripts were highly dependent on system calls (even basic ones like fork) that weren't implemented in Windows at the time. I nearly pulled my hair out trying port those scripts. Any real Perl guru will still tell you that Perl isn't 100% portable. There's even a lengthy webpage about the differences between the varous ports and quirks of the various platforms. These are significant differences between the Perl ports: including long lists of "unimplemented functions". In fact, what reminded me of this pet peeve was Tim Bray's post about the differences between some regular expression processing he did in Java and Perl. His original post was largely about the Java's superior performance and his surprise at that difference. But his follow up post mentions that Perl was returning different results on different platforms. He suspected that the Unicode processing was buggy and causing differing results on differing ports.

I suppose this happens in Java from time to time as well. I've had customer issues where they wrote some code that works differently in BEA WebLogic than it does in Sun Java System Application Server. But in Java that kind of problem is generally considered a bug and happens fairly rarely. I've "ported" lots of Java code in my day and it's a pretty painless process. There certainly aren't any "unimplemented functions", like those that haunted me in my own Perl porting days.

Bottom line: you can legitimately argue about how Java should be licensed. There is a reasonable discussion that can be had about the tradeoffs between compatability and openness. But TCK's are the test driven development of binary compatability. Without the TCK tests (and the ability to enforce them), implementations will not be 100% compatible. Perl is the perfect example of the technical reasons why compatability is hard work. If you throw in the economic factors that entice vendors to create lock-in, incompatibility is assured. Why wouldn't Nokia be interested in creating an "enhanced" version of Java that can only run on Nokia phones. Microsoft certainly saw value in creating a Windows only version of Java.

PS:
As a side note, this is one of my philosophical problems with the SWT library. Here is a quote from the front page of the SWT project: "developers need to understand that applications can potentially behave differently to match the operating system behavior". Although the author goes on to say that a well written program can adapt to these differences, he also suggests "smart developers will test SWT applications on every platform which they are to be delivered on". IMO, this is completely contrary to the philosophy of Java. I develop code all of the time that I have no idea what platform it will run on. I develop code that I know will run on Windows, and I do not own a Windows box. I don't own an AIX box either and I know that some of my code has been run on AIX as well. I'm going to start work on an open source Java project. How will I know in advance what platforms the users will own? And to make the issue personal, despite being "native", the SWT Mac port has always felt like a hack to me.


(2004-08-30 20:17:57.0) Permalink Comments [5]