ot so many years ago, when you went to buy a new car, among the many decisions you’d have to make about your “options” was whether or not you wanted to shell out some extra cash for airbags. I imagine a lot of consumers were nonplussed, not because the decision was very hard but because the airbag itself just isn’t one of those things that one expects to make a choice about. It’s sort of like asking whether you want locks on the doors. You don’t need them, maybe, but then again, you sort of do.

Choice is a wonderful thing. So is process and so is community. And above all, standards. Because what are airbags really, except a standard that will, eventually, be fully implemented?

XML, and its many derivative standards, are in very nearly the same implementation phase as airbags. Soon, no developer will have to answer the question: Do you need XML?

The question is: why is anyone still being asked?

I’ve been thinking plenty about process and standards this week, while attending JavaOne in San Francisco. And I’ve noted a discernibly more relaxed countenance on the faces of Sun Microsystems executives as compared to last year’s JavaOne, a fact which I attribute to the recent release of the Java Web Services Developers Pack and the J2SE 1.4, which ships with JAXP, an API that provides functionality for parsing and transforming XML.

On the other hand, the realization that the ship date for the 1.4 version of the J2EE, with these same XML capabilities built in, would slip by a quarter, was not happy news. Sun executives, of course, are making light of it, concentrating on the fact that the Developers Pack download fills in the gap for those who need it.

Sun has taken a beating in the media during the last year, owing to the fact that Microsoft was on track to ship its .NET platform, with XML Web services support built in, well before Sun could integrate XML into the enterprise version of Java

At a press conference Monday, Java’s creator, James Gosling bristled at criticism over the lack of “native” support for key XML technologies, required for building web services, in the current version of the J2EE.

“The fact that they’re plugged in vs. shipped in a bundle means nothing other than the way that they’re packaged,” Gosling said. “When something is a separate piece, it doesn’t mean it performs worse; it doesn’t mean it has less function; it doesn’t mean it’s less integrated. It just means if you don’t want it, don’t buy it.

“The distinction that is often lost is the distinction between an available technology and a required technology. When we say XML becomes available in the J2EE 1.X spec, the thing is that that’s when it’s required. In actual fact, it’s been available for some time. Lots of folks have been plugging XML into the J2EE for a very long time. ”

To a great extent, Gosling is right. XML and Web services support are available right now—in several packages—for any Java developer who chooses to use them.

The problem is that Gosling assumes that this is a choice that anyone actually needs to make. Do you want door locks? Yes. Do you want airbags? Yes, please. Do you want XML and SOAP and Schema and WSDL? You bet. XML is standard equipment. Is now. Has been for awhile. Why are Java developers still being asked to consider it as if it were some luxury option package?

The simple answer is process. Lots of process. Big, fat, open-ended, committee-driven, discussion-laden process. And that’s not a bad thing—or hasn’t been in the past. Process is part and parcel of Java. There’s much to be said for a method—like the Java Community Process (JCP) —that gives smart, committed people a forum to contribute to Java’s future development. The argument that process makes Java stronger is not lost on me. But at what price? How much longer can developers, and third-party vendors, and Sun itself, afford to choose virtue over time-to-market?

Of course virtue is not the only reason that Sun embraces design-by-committee for Java. The JCP has a hidden benefit, too: it allows the company to eschew some portion of the responsibility and cost for Java’s growth. This isn’t a criticism, per se. Having never attempted to be a leader (at least, not directly) in the Java tools business, Sun has never really been able to capitalize, financially, on Java’s success and therefore strong control of research and development costs is simply good business.

But the software marketplace that Sun faces in 2002 is very different from any that it has faced in the past. For starters, we needn’t debate for a second what Microsoft’s policy is going to be when it’s given an opportunity to bring key technologies into its development environment. In fact, in the case of XML-based Web services, Microsoft roundly beat Sun in the standards arena, the marketplace, and the media.

In a conversation on Tuesday at JavaOne, Jon Bosak, Distinguished Engineer, a man who has nurtured the creation and standardization of XML and related technologies from its SGML crib in the early 90s, was frank about the fact that Microsoft had moved swiftly to adopt XML technologies, effectively taking Sun and the engineers on the XML working groups quite by surprise when they fully realized its intentions.

Standards Processes Are Inherently Slow
“The W3C has a track record of delivering technologies that have been through an appropriate process of due diligence. And have gone through a standard process that we all buy into,” said Simon Nicholson, Manager-Market Strategist for sun’s XML Technology Center. “That stuff takes time. There is no secret sauce there. There is no way of short circuiting the fact that you have to set people down at a table and work through the issues, come to a consensus of opinion. Standards processes like that have existed for decades.”

Said Bosak: “Any real standards process is going to operate much more slowly than the way that Microsoft does things. End of story.”

But should it be? XML and Java may already coexist but no one can deny that the 1.4 version of the J2EE—with all of the requisite technologies of the day present together—is already going to come nearly a year behind the same integration delivered by Microsoft. To speculate on the cumulative effect of further process on Sun’s nimbleness with Java is disheartening.

Is slower growth a tradeoff that the Java development world at large is prepared to accept in return for the nobility of egalitarianism? Certainly no one expects Sun (or Microsoft or anyone else) to abandon the formal standardization process. But Sun’s decision to cycle all revisions through the formidable committee of the JCP is a ponderous weight. Technology changes too rapidly. There are well over 200 Java Specification Requests currently under consideration at the JCP—and only 6 have been rejected. Sun is running underwater.

Where Sun shepherds, Microsoft corrals—complete with lasso and rope burns. And, hey, if the planks of the gate happen to hit you in your fluffy flanks on the way in, well that’s just a small tax you pay for the privilege of having your haunches delivered someplace safe and warm for the night.
Don’t get me wrong: if I were some manner of beast, I’m quite sure I’d prefer to be gently lulled to my destination rather than hogtied and dragged, but when darkness falls I want to be curled up in a foul pile of hay, right next to the trough. In other words, the sooner I get where I’m supposed to be, the better off I am.

At one time, in a far simpler age, software developers could afford to be as concerned with the journey as the destination. But today, what I see are developers with mountainous workloads and companies under incredible pressure to wring as much from technology as they possibly can, immediately.

And it’s rather ironic to note that this issue is a mirror of the one hotly debated in the VB world for the last year. Many VB developers were bitter to find that Microsoft had changed the language significantly in .NET, without consultation, with seeming disregard for the developers who use—and like—VB 6. But the number of those who are still upset decreases steadily. To a great extent, VB developers have come to find that there’s enough to love in VB.NET to forgive the rough and rather heedless manner of its administration. For those who have given .NET a fair trial, the reaction to the dubious handling of the transition seems to be: necessary medicine.

As I look at Java, I see the number of “extra” APIs necessary for modern development increasing by leaps and bounds. The number of both proprietary and open implementations increases as well. Because the process hasn’t caught up with the technology, there’s no approved standard, so developers have to make quick and sometimes ill-informed choices. Some feel overwhelmed. And I think it won’t be long, really, before Java developers are ready for a little necessary medicine of their own. For now, they can be grateful that third-party Java vendors are reacting with far more expediency and mindfulness of market demands than Sun is, and that, in the meantime, they can always shell out extra for the airbags.