Columns

Family Matters

• By Tony Baer
• September 27, 2001

But the Sun–Microsoft battles, which concerned proprietary extensions to the JVM, might prove barely a sideshow compared to Sun's and IBM's dispute over Enterprise Java. The difference this time is that IBM is playing smarter than Microsoft, licensing basic Java but not J2EE, so it won't have to worry about lawyers or subpoenas.

By now, the debate over Sun's stewardship of Java standards sounds like a broken record. Obviously, IBM can't afford to have a major platform rival dictate its agenda, and maybe it doesn't like the licensing terms either. IBM claims it is "100% committed without reservation" to EJBs (part of J2EE), but has left plenty of wiggle room. At JavaOne, IBM repeated its commitment to EJB 1.1 but not the 1.2 version that will be part of the J2EE spec—well, not yet anyway.

The kicker? While Sun views Enterprise Java as the universal app environment that runs anywhere, IBM views Linux as the true cross-platform technology. Nonetheless, Enterprise Java remains in IBM's interest since the effort to port OS/390 and AS/400 apps to Linux strains credibility.

With Microsoft distracted by its battles with the Department of Justice, Sun has a rare, added opportunity to make the case that Enterprise Java should become the de facto e-commerce app environment standard. Despite the merits of its arguments that international standards bodies often take too long to deliberate, Sun's refusal to make even token gestures risks squandering the PR opportunity it has been presented of proving it's not another Microsoft.

Obviously, peace could break out at any time. But even if Sun, IBM and others like Hewlett-Packard drop their swords, interoperability issues won't evaporate into thin air.

At JavaOne, Sun staged a "Deployathon" to demonstrate that EJBs for a simple e-commerce app could run identically on a half dozen or so different app servers. Sun's demo was equivalent to taking a simple page of basic HTML text and running it on different browsers.

Yet when more sophisticated functions are added to the mix, developers will have to learn the differences between app servers, just as they must now master the differences in how Oracle, DB2, SQL Server or other relational databases run SQL.

For instance, when and if WebSphere, WebLogic, Bluestone's Total-e-Server (formerly Sapphire/Web) or other EJB servers support container-managed persistence—a form of session maintenance and object-relational mapping—developers will have to know what each product's defaults are. The same goes for load balancing and failover. Compliant products might be similar, but they won't ever be the same.

This doesn't make standards meaningless, but market forces are far more important. Remember our concern over Java balkanizing like Unix? Unix balkanized in the mid-1990s, but in recent years Solaris has emerged as the market leader.

We wouldn't be surprised if the market also pushes some form of Java convergence, but we suspect that it won't consist of a single body of standards. The results may look very familiar to HTML developers who are forced to use lowest common denominator strategies focused on "safe" HTML features supported by all browsers. For instance, while Sun might eventually prevail with Enterprise Java standards, IBM could implement a superset that is similar.

All of these Java implementations will have to interoperate, which means using "safe" Java classes. Any doubts? Look at the automotive electronics industry. Delphi, which has endorsed HP's rival Chai, a "clean room" embedded Java that was developed independently of Sun, may have to work with some of the 60 consumer electronics manufacturers who have endorsed Sun's J2ME, Java multimedia edition.

In the long run, each Java sector will likely pick a winner, leaving developers to bridge the gaps. And, like any dysfunctional family, vendors will continue to love Java to death.