Standing in the Field
Notes from SJS Application Server Field Engineering
Standing in the Field
Notes from SJS Application Server Field Engineering
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.
| « November 2009 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | |||||
| Today | ||||||
Here here!
Unfortunately, poor developers probably write many, many lines of code before they encounter the portability problems. I sure wish this were an area for cooperation on a standard rather than differentiation.
Posted by Matt Ingenthron on August 30, 2004 at 10:18 PM PDT #
However, I do remember the first time I needed to run Perl on Windows. That was pretty irritating. It wasn't a particularly large amount of code (2000 lines?), but it took about 10 hours of work to get it to run stably and correctly I think (while also running on FreeBSD correctly). Once you get used to the differences you can at least plan ahead for them, but it's still annoying and extra work.
I used to like Perl a lot, but it became increasingly irritating - making the code very clear and precise is actually a bit of work. One of the problems with scripting languages in general. (The less I liked Perl the more I liked Java). However, using Perl so much did help me understand the power of regexps, hashs (associative arrays) and so on.
I also remember trying to use the "modperl" Apache module, which keeps the code in-memory between requests in the name of performance. (real memory hog). It may be a lot better now (been many years) but at the time it was very flakey running Perl like this. To get anything to run reliably in such an environment, you really had to develop for it from the start.
I don't use Perl that much these days, but unfortunately I do have to use PHP fairly often. Though I think it has fewer cross-platform portability issues, it has a number of cross-version issues. The developers just love to add new features and break backwards compatability at any old time, instead of having releases which are primarily/only bug-fixes. This can get very irritating, particularly when dealing with third party software, which can have pretty specific dependancies. The language is also rather icky, and a number of critical libraries are just plain dumb. Some of these issues have been papered over, but still...
With Java I can develop on 1.5 and deploy on 1.3 with little worry - I was doing this last week. And that was on a completely different OS/CPU platform as well.
Posted by Chris Rijk on August 31, 2004 at 03:02 AM PDT #
Posted by murphee on August 31, 2004 at 09:31 AM PDT #
I didn't mean to make an argument against open sourcing Java. I do, however, believe that it illustrates some of the trade-offs between openness and compatability.
In Tim Bray's case, Kevin Burton wanted to create and distribute a performance enhanced version of Java 1.4. Assumably using the Java name and without executing the entire TCK. This is an amount of openness that we are very unlikely to see. This kind of fork is against the philosophy of Java IMO.
But perhaps there is a happy medium. I don't want to dismiss the possibility of an open source Java. There have already been attempts to create cleanroom versions of Java. There are things that Sun could do to make the TCK licensing more friendly to those implementations.
Or maybe Sun would consider opening some or all of its JDK code under an open source license. (While still keeping the copyright to the Java name and enforcing the TCK requirement.)
But, almost by definition, the more freedom you allow developers the more compatibility becomes an issue. There are ways that Java can protect compatibility, but the point of the blog entry was that to repudiate those who think that compatibilty was easy in the open source world.
Posted by David Ogren on August 31, 2004 at 12:29 PM PDT #
Posted by murphee on August 31, 2004 at 02:13 PM PDT #