Browse DevX
Sign up for e-mail newsletters from DevX


The High Price of Process

By forging Java in the crucible of the JCP, Sun gains moral credibility, but risks falling even further behind in the rapidly-evolving technology marketplace.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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?

Is slower growth a tradeoff that the Java development world at large is prepared to accept in return for the nobility of egalitarianism?

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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date