Jon Udell: Freedom, Control, and Java

Tangled in the Threads
Jon Udell, February 09, 2000
Freedom, Control, and Java

Strong opinions about Sun's stewardship of Java

A while back, Jari Mäkelä noted:

Java is surely hugely popular but we are far from the "any platform" slogans of early Java days. There are production versions only for Wintel and Solaris and betas for Linux and AIX.

It's certainly an odd situation. "Write once, run anywhere" has devolved into, as one newsgroup wag put it, "write once, debug everywhere."

For Linux users, in particular, it's been a long and frustrating wait for a mature and current JDK to appear on their chosen platform. Until recently, the choice was between JDK ports from Blackdown and IBM, neither of which was current with Sun's Java 2. When I faced this choice a while back, I tried Blackdown's JDK 1.1.7 (versus IBM's JDK 1.1.8) more or less at random; it was far from clear what to expect in either case.

More recently, a beta version of JDK 1.2.2 for Linux has been available from the Blackdown site.

According to Thomas Lockney:

I've worked with both. The Blackdown/Sun code is more up to date (very cool if you want to use any of the new features of Java2), but the IBM code performs a bit better. There are even some kernel tweaks available to help improve performance even more (see http://www-4.ibm.com/software/developer/library/java2/index.html). I'm more inclined to stick with the Blackdown work -- for some reason, I've had better success getting certain products to work under it (including Allaire's JRun).

But isn't the situation changing now? This week, another correspondent pointed out that Java 2 for Linux is (nearly) available from Sun. Doesn't this indicate that Sun's now fully behind Java for Linux?

Bjørn Borud:

No, it does not imply that the product has superior, or even acceptable, quality. Merely because Sun created the Java programming environment doesn't mean they are the best implementors.

This time Sun based their release largely on the work of unpaid volunteers. Of course by now everyone knows who did the work and what Sun did in return for them -- i.e. they never gave them any credit for their efforts.

What Bjørn's referring to is Sun's Dec 7, 1999, announcement that it would ship a Linux version of Java 2 Standard Edition (J2SE) v 1.2.2 on Linux. Mentioned in that press release was Sun's partnership with Inprise, which supplied its Just-in-time compiler (JIT) technology. Conspicuously missing from the press release was mention of the efforts of the Blackdown project. Sun corrected this omission in another press release on the following day which included this mea culpa:

This week's announcement would not have been possible without the collaboration of Blackdown, a group of developers and enthusiasts around the globe. Since its inception, Blackdown has been a provider of Java technology for the Linux platform. Their dedicated effort over a number of years has laid the foundations for this release of the Java 2 platform port to Linux; in particular their effort was critical to the success of this release, and earlier omissions with respect to this contribution are deeply regretted.

Amplifying that apology was this posting, on the JINI-USERS mailing list, from Jini architect Ken Arnold:

The press release was messed up. Pure and simple. Sun knows that Blackdown did a lot of work that was in that release, Sun even had Blackdown in the confidential Q&A about the release, but, through a typical level of big company miscommunication, didn't get it in the press release.

Sun is *really* sorry. Believe it or not. I've talked to the person who is in charge of this messaging and she was about as sorry about it as one could hope.

Fair enough, but none of this answers Jari Mäkelä's original observation: that after more than five years of Java hype, production versions of the supposedly portable language are still hard to find for many platforms.

Java's prospects, client-side and server-side

Way back in June 1997, I wrote a column for BYTE in which I argued that Java's future was much brighter server-side than client-side:

It's a peculiar moment in our industry's history. The Java buzz is intense. And yet when you look at the Web applications that people actually use every day to do their work, you invariably find that there are no Java applets in the mix. The universal client today is still the HTML browser. The universal client of tomorrow will be the HTML/JavaScript browser.

Client-side Java is a glorious vision that will not change the way most people use the Internet anytime soon. Why not? It's just more than what the majority of today's computers and networks can readily push. So what are millions of people running every day? Server-based applications that feed the universal HTML client.

I took some flak for that column, but I think events have proved me right. In their different ways, the Microsoft and Netscape browsers are evolving richer UI technology that's built around native-code widgetry and a scriptable Document Object Model, not a Java-based replacement GUI. Meanwhile, Java application servers -- such as IBM's WebSphere, Bluestone's Sapphire/Web, Sun's NetDynamics, and others -- are being touted, in many IT circles, as the safe, scalable, open way to deploy mission-critical network services.

However Bjørn -- who works for a search-engine company -- cites evidence that on the Internet (as opposed to intranets) even server-side Java (in the form of Java Server Pages and servlet technologies) is far outpaced by PHP, ASP, and Perl-based CGI.

He adds:

I think Sun should think about this for a while. Their selling point is portability, yet Java only runs well on a few platforms and Sun, in their misguided effort to promote Solaris, do not seem keen on remedying this any time soon.

Fred Pacquier observes that, while Java may indeed be finding favor on intranets,

Intranets are corporate programming, and corporate programmers tend to follow the official, guru- sanctioned trends by the book: objects, client-server, multi-tier, now Java. These are slow-moving cultures that need multi-year evolution paths, and in which you get the "hairy eyeball" whenever you mention non-mainstream, unsanctioned or underhyped tools such as PHP or or Zope or whatever.

Whatever the market reality turns out to be, I feel Java has already lost "geek-mindshare", an all-important, if intangible, asset. Too many years of unchecked hype without much result, and a lot of negative feedback on Sun's politics. Heck, even relative newcomers (in terms of hype exposure and public awareness) like Python and Zope have more "geek-mindshare" right now.

On open-sourcing Java

The sentiment is nearly unanimous, in the BYTE.com newsgroups, that Sun should open-source Java. Bjørn Borud states the position well:

Linux is just one of many operating systems Java should have been ported properly to years ago. Now that it is somewhat supported, well, good for the Linux community, but it still isn't enough. There are still many platforms left that have no decent Java environment. Solaris, Windows and Linux is not enough. That's not "run anywhere." Sun cannot possibly support every platform, yet there are thousands of people who would be able to contribute.

But not everyone agrees. Cedric Berger makes the following points:

AIX and HP-UX also belong on the list of JDK 1.2 platforms, which makes total coverage quite respectable.

Sun's biggest fear is a Java split, such as happened to UNIX and could perhaps happen to Linux too.

In an extremely long and thoughtful posting, Bjørn Borud hotly disputes that a Java split would be a likely result if Sun were to open-source Java. This has certainly not happened to Perl, Python, or PHP, he notes. He further argues:

That Mozilla, though arguably much more complex than the JDK, has been successfully ported to far more platforms.

That the current situation with Java is already fragmented, as between Sun and Microsoft.

That UNIX is less fragmented than it formerly was.

That Java is artificially popular in corporations because (as Fred Pacquier also noted) decisionmaking tends to be governed by guru-sanctioned trends.

That a strong and open reference implementation would incent contributors to strengthen Java.

Has Sun, in fact, bungled Java? Does it fail to understand that open-sourcing the platform is the only way to realize Java's ultimate goal of universality? Did Sun's Dec 7, 1999, withdrawal from its earlier (April 1999) proposal to standardize Java under the aegis of the European Computer Manufacturer's Association (ECMA) standards-making body confirm that Sun will never "get it" when it comes to Java and open source?

In a recent column, Tim O'Reilly -- who as much as anyone would like to see open-source reimplementation of Java -- calls attention to the issue of ownership, and "moral rights."

Citing Eric Raymond's The Cathedral and the Bazaar Tim notes: "Even the most promiscuously open of open-source projects have 'owners' in at least a moral sense."

In an email to me, Tim elaborated on this point:

Many open source advocates hold Sun to a higher standard than that to which they hold open source developers like Linus Torvalds or Larry Wall, who despite their open licenses reject features proposed by others that don't fit their vision of the software they have created. The difference is that Larry, Linus, and other open source leaders do rely on their moral authority and persuasive creative vision rather than restrictive licensing terms to enforce their decisions.

Nevertheless, Sun is under attack from the industry's "top predator," Tim says in his column. The company is "walking a tightrope between making Java ubiquitous and protecting it from those who would undermine its ubiquity by 'standardizing' alternate versions of it."

He adds:

"Sun's position seems counter-productive when taken out of context, but I'm not sure that they don't have to use every weapon at their disposal to try to keep Java's vision alive."

I don't think that Sun has ever presented the SCSL (Sun Community Source License) as anything other than a compromise solution, and a work in progress.

While it's true that Perl, Python, and PHP are not in danger of splintering, they are not in the top predator's crosshairs in the way that Java is.

Said Bill Joy and Richard Gabriel of the SCSL:

"In defining the Sun Community Source License, Sun has tried very hard to get it right, but maybe it isn't perfect. Naturally, we believe so much in our open process that the license itself is subject to that same process, and as participants need changes in the license, we will make them."

All this suggests three things:

Sun does have the moral right to control Java,
And there is real pressure on Sun (from Microsoft) to exercise that right,
But participants do need changes in the license, and Sun's responsibility to the Java community is to make those changes.

Following from these points, my question is:

How, specifically, should Sun amend the SCSL to strike the correct balance between control and freedom?

Drop by the programming newsgroup and let us know what you think is the right way forward for Java.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

This work is licensed under a Creative Commons License.