Java developers, J2EE developers in particular, preach portability like a religion. “Don’t be tied to one platform,” they’ll tell you. Indeed, platform neutrality is a huge advantage of the J2EE architecture, allowing developers, in theory at least, to build applications that can exist independent of the underlying operating system or systems in use by an enterprise.

J2EE’s trademark portability is largely provided by application servers, which are responsible for hosting J2EE applications and providing a consistent Java-friendly environment for them. However, many server vendors routinely provide custom, proprietary extensions to J2EE’s API. If developers take advantage of these extensions, their applications may not run outside of that application server. How do you see these proprietary extensions affecting J2EE in the future? Sound off in our discussion.

The “Cajun Crisis”
Viewed in the context of J2EE as a platform-agnostic application framework, the existence of these proprietary extensions to J2EE’s API is at the very least curious. The vendors that provide them say that these extensions provide needed functionality that’s missing from the bare J2EE specification. Java developers, on the other hand—always on the lookout for a power play—sometimes say otherwise.

The latest example of the controversy that custom J2EE extensions can cause is BEA’s “Cajun” extensions for its WebLogic application server. Cajun provides a visual toolkit and runtime support for building Java Web services that run on the WebLogic platform. Given a lack of any formalized, Sun-endorsed standard Java classes for building Java Web services, BEA’s Cajun fills a rather big hole in J2EE’s feature set.

But what’s the cost of filling that hole? By leveraging the additional functionality provided by any proprietary extensions, aren’t the J2EE developers in effect locking themselves and their applications to one single platform, provided by a single vendor? According to the results of a poll we recently ran on the subject, a majority of Builder members who responded seem to think these extensions do indeed threaten Java’s portability. Figure A shows the results of this poll.

Figure A
Java’s platform neutrality may indeed be threatened.

Vendor lock-in: Mountain…
There’s certainly a business reason for an application server vendor to attempt to lock developers to its product. Doing so can ensure future sales of their products and allow the company an opportunity to cross-market related products and services. This strategy has worked in the past for the likes of IBM, Microsoft, and even Sun itself.

Although the company has recently backed off from its stance, BEA had initially planned to keep Cajun proprietary and available only on WebLogic. That has led many Builder members to conclude that vendor lock-in was exactly what BEA had in mind, with member ecerrillos even going so far as calling for a revocation of BEA’s J2EE certification.

Member javacarl‘s comments typified the general mood:

“How can BEA claim to have a truly J2EE-compliant app server if, in fact, the custom extensions allow code to be run only on BEA WebLogic app servers? It sounds to me like BEA is doing a ‘Microsoft’ by locking in the implementation of J2EE apps on its platform.”

…Or molehill?
While member t_altamimi agreed that Cajun violated the key “write once, run anywhere” premise of Java, to accuse BEA of “pulling a Microsoft” was simply overreacting, since proprietary extensions often find their way into the core language set.

“Java evolves when vendors like BEA spend R&D dollars on technology, such as Cajun, and they submit such technology as proposals to Sun for future versions of Java and J2EE. If Sun were to carry the entire burden of advancing Java on its own, Java would never have advanced as quickly as it has.”

Hurwitz Java analyst Tyler McDaniel said that one vendor can’t really change the nature of J2EE as a fundamentally open architecture. While it’s always bad news when a vendor tries to force developers to use a particular toolset, he thinks vendor lock-in in the J2EE space would be difficult to achieve.

“There are too many vendors cooperating on the [J2EE] specs to let this happen. The JCP [Java Community Process] will be able to keep things neutral.”

It’s your turn
What do you think? Will Sun be able to keep J2EE on a level, open keel, or is J2EE being fragmented by application server vendors bent on locking you into their systems? Share your opinion in our discussion.