Java turf wars kick off
Recently, I wrote a column that asked the question: Is this the end of Java as we know it? That question was triggered by a proposal to the Java Community Process (JCP) for an enhancement to the Java standard after (instead of before) that enhancement was embraced by members of the JCP, namely IBM and BEA.
For years, the JCP has been the venue for vetting proposed changes to Java technologies. Java is comprised of many moving parts and components, including the various footprint-specific versions of the Java Virtual Machine (JVM). Virtually all of these individual Java specifications and any upgrades to them -- known to Java aficionados as Java Specification Requests (JSRs) -- are first hashed out and polished by the contributors to the JCP before being officially incorporated as a Java standard, or supported in Java standard-compliant offerings.
Historically, when the official process for creating extensions to Java has been bypassed by a single company in a way that's considered a violation of the "write once, run anywhere" promise of Java, that company must either warn developers that they are about to leave the sanctuary of the Java promise (the point at which a developer invokes such vendor-specific extensions), or, in the most well-known cases, face the ire of Sun.
When Microsoft offered Windows-specific extensions to its Java Virtual Machine (JVM) without raising the requisite red flags to developers, Sun sued Microsoft in a case that was eventually settled out of court in 2001. The reverberations of that case echo through the industry to this day.
Similarly, although no lawsuit was filed, Sun was outraged by IBM's November 2001 introduction of the Eclipse integrated development environment (IDE) as an open-source alternative to the Sun-endorsed IDE, NetBeans. Eclipse offers developers several exits from the Java campus, but the one that Sun focuses on is an IBM-developed graphical user interface (GUI) for Java known as SWT. To preserve the "write once, run anywhere" promise of Java, Sun encourages users to stick with SWING (which is the default GUI library found in NetBeans).
Whereas previous transgressions against the tenants of Java have been unilateral, a recently announced joint effort between IBM and BEA may have ushered in a new era for the Java ecosystem. The two members of the JCP, both of whom are contributors to the JSR for J2EE, bypassed the traditional propose-ratify-support sequence by collaborating on three J2EE extensions (Service Data Objects, Timer for Application Servers, and Work Manager for Application Servers). They promised support for the extensions in the next versions of their application servers first and proposed them to the JCP after.
When last counted, IBM and BEA, which have been jockeying for the J2EE market leader crown, collectively controlled 66 percent of that market. Much the same way the collective presence of IBM and Microsoft left the rest of their competitors with little choice but to embrace the various Web services specifications that the two companies collaborated on, the combined might of IBM and BEA in the J2EE marketplace affords them the luxury of leaving the rest of the J2EE market with little choice but to embrace any specification that the two decide to jointly support.
From a procedural point of view, the parallels between IBM and Microsoft's pre-emption of the World Wide Web consortium (W3C) in an effort to create de facto (not officially ratified by any standards group) Web services standards and IBM and BEA's pre-emption of the JCP are strikingly similar, and perhaps now, even formulaic.
Many newly proposed specifications in 2003 -- especially Web services ones -- have or will earn de facto standard status as a result of either IBM or Microsoft (or both) partnering with next biggest leader in whatever market is relevant to the specification (such as Verisign in security), and jointly announcing their collaboration on that specification.
Unilaterally, neither Microsoft nor IBM are powerful enough to force these specifications down the throat of the industry. When they partner with each other or with the next biggest gorilla in each market segment, where IBM and Microsoft go, the industry must follow. IBM's collaboration with BEA appears to be just another perfect execution of this formula.
Though the two companies and Java chaperone Sun might disagree with my assessment on the grounds that the proposed specifications are already on track in the JCP as JSRs 235, 236, and 237 (all of which have IBM and BEA listed as their leaders), my feeling is that the submission of these proposals to the JCP was largely symbolic. Whereas other JSRs, including the more recently proposed JSR 238 for a Mobile Internalization API have a list of supporters that's longer than the list of leaders, the three JSRs put forth by IBM and BEA had no other supporters besides themselves when I last checked.
Looking at the formula, the JCP looks to be playing very much the same role for IBM in creating de facto J2EE standards that OASIS (Organization for the Advancement of Structured Information Standards) plays in creating de facto Web services standards. They are both regimes with an intellectual property policy in place (always necessary for any specification where other industry members are invited to participate) and, to eyes of undiscerning customers, regulators, trustbusters, conspiracy theorists (but not this one), naysayers, and the press, the connection of their names with specifications creates the perception that an attempt at domination isn't afoot when it really is.
To wit, as the JSRs in question run their course, and should some version of them finally be ratified, my sense is that the overall impact on them having been run through the JCP's regimen will only be slightly different, if at all, than had they not. In either case, the agenda of IBM, which on numerous occasions has told me that they'd like to see control of Java wrested away from Sun (even though Sun claims not to control it), will have been served.
To me, this entire power play appears to have marginalised the JCP in much the same way that IBM and Microsoft appear to have marginalised the W3C which is why I openly wondered in my column if this was the end of Java as we know it. I talked with Jonathan Schwartz, Sun executive vice president of software, to get Sun's perspective on the issue.
In my interview, Schwartz disagrees that the move by IBM and BEA has compromised the integrity of Java or the JCP, saying that the reason that BEA and IBM took the specifications to the JCP was not to mask a power play (as I have posited), but rather "because the market looks to the JCP for the standards they deem safe." Schwartz later characterises that safety as being the competition and the substitution that the JCP enables to the benefit of customers. Schwartz believes that if anything, the gravitational pull of the JCP "frustrates IBM."
Schwartz made it clear that Sun is not to be counted out. Akin to the way a seemingly defeated Superman exposed to strength-sapping kryptonite somehow manages to escape to save the planet, Schwartz talks about Sun's own J2EE offering -- AppServer 8.0 -- as though it's Sun, Java, and the industry's savior against the maniacal 800-pound gorillas looking to dominate the world. It just might be. While time will eventually bear out Schwartz's prediction, let me be the first cynic to concede that AppServer 8.0 might very well be the secret weapon that throws a wrench in the works for IBM.
As Schwartz tells me in the interview, AppServer 8.0 serves multiple purposes. By virtue of the fact that it was compliant with the most recent version of J2EE (version 1.4) less than two weeks after that specification went through the JCP's final balloting process in November 2003, and that it wasn't until January 2004 that IBM supported the specification in WebSphere, IBM can't badmouth the JCP standards process as being too slow. All of the JSR members have equal access to the evolving specification before it gets ratified, which is what enables those members to release a compliant application server on a timely basis.
Schwartz argues that if IBM were that sensitive to time, it would have had a 1.4-compliant server within days of the specification being ratified by the JCP. But, as if being first out with a J2EE 1.4 compliant application server weren't enough, AppServer 8.0, according to Schwartz, also one of the first application servers (beating even Microsoft) to support the Web Services Interoperability Organization's (WS-I) Basic Profile. Whereas IBM and Microsoft started the WS-I, Sun was a latecomer and for it to bring its technologies up to speed with a WS-I profile before one of the founding members certainly says something about Sun's commitment.
Frankly though, if those claims are true, I find them to be mostly moral victories for Sun and its own developers. But the two most tangible effects of AppServer 8.0 will be felt in its price and the platforms it supports-it's free, no strings attached, and it runs on Solaris, HP-UX, Linux, and Windows.
Prior to AppServer 8.0, Sun was viewed as a bit of a laggard in the application server camp. It was almost ironic that Sun invented Java, but couldn't match or even come close to the success of IBM's WebSphere or BEA's WebLogic. Sun's early resistance to Web services, which Schwartz characterizes as an "orthogonal" view, and the way Sun got sucked under by the political undertow of the Web services movement were probably contributors to the unimpressive performance of Sun's application server in the market. Now, in a sort of Sun-meets-JBOSS (JBOSS is a free, open source-based J2EE server) offering that amounts to the reference implementation of the J2EE 1.4 specification, that runs on multiple platforms, and that is also aligned with (as opposed to "orthogonal to") the Web services movement, how can any organization be justified in not taking a closer look, especially those already committed to Java (as opposed to ones also considering Microsoft's .Net).
Is Schwartz the new industry superhero? Maybe. He and I talked about everything from the JCP to Linux indemnification to what Sun is going to do to win Windows developers over to Java. Read the interview and then you decide.