Posted by monsonhaefel
on December 2, 2003 at 10:21 PM PST
IBM and BEA are working within the JCP process - they need the JCP.
A Microsoft wonk asked me an interesting question yesterday: Will IBM and BEA make the Java Community Process obsolete? The impetus for this question was the recent release of three J2EE "specifications" by IBM and BEA, which you can review here . Rather than develop these specifications from scratch within the JCP process, as is done in many cases, IBM and BEA decided to propose three new JSRs (235 , 236 , and 237 ) based on specifications that they had already developed. Is this wrong? Does this approach circumvent the JCP Process? Will IBM and BEA make the JCP obsolete? The short answer is, "No".
The Java Community Process (JCP ) is designed to facilitate the creation of standard, vendor-agnostic Java technologies. This is my quick and dirty definition, the keys to which are the words "facilitate" and "vendor agnostic". The primary objective of the JCP is to provide a framework for defining Java standards. In most cases, an expert group develops the standards based on a set of objectives defined by the proposed JSR (Java Specification Request). In other words, usually the specification is grown from scratch under the auspicious of the JCP. This, however, is not a requirement. The actual specification can be grown from scratch (e.g. JSP, JSF, EJB, etc.), based on established non-JCP standards (e.g. CORBA, DOM, SAX, ext.), or an existing implementation or architecture as is the case here. It really doesn't matter very much as long as the JCP accepts the JSRs, approve their progression through community and public drafts, and endorses the final specifications. The bottom line is that the JCP is not supposed to stifle the development of specifications seeded outside of the process - to the contrary. If leading vendors want to hammer out the details before beginning a JSR, then so be it. Who cares how it got started?
Contrary to what my friend from Microsoft Land may say, the JCP is not doomed to obsolescence – not by a long shot. The truth is, IBM and BEA need the JCP. Neither of these companies could go it alone, outside the JCP. For example, before EJB/J2EE, both IBM and BEA marketed proprietary server-side component models. IBM's was called Component Broker and BEA's was called M3 (a.k.a. Ice Berg). Both vendors abandoned their proprietary architectures in favor of Enterprise JavaBeans. Why? Because their customers had more confidence in standards based solutions than proprietary ones. It’s the money that talks, and the money (customers) prefers standards to proprietary solutions. That hasn't changed and since IBM and BEA are not a standards organization, they will always need the JCP – or something like it - to manage the standards on which their products are built.
A little history illustrates the necessity of a standards organization like the JCP. In the mid to late 90's CORBA, not J2EE, was the leading application server standard for non-Microsoft vendors. The OMG defines the CORBA standards and initially vendors fell in line with those standards. But after Visigenic and IONA emerged as the market leaders (not unlike IBM and BEA today) they became more antagonistic toward the OMG. Now to be perfectly honest, I think the OMG was getting a little carried away, but that doesn't change the outcome. IONA and Visigenic thumbed their noses at the OMG to their own undoing. Where are Visigenic and IONA today? Are they still the major players? No, I'm afraid not. They've become minor players in the J2EE market. EJB and J2EE came along and everyone – vendors, customers, and developers – jumped the CORBA ship and went to J2EE. J2EE is the centerpiece of server-side products in Java Land because it’s a vendor agnostic standard that vendors respect and follow. IBM and BEA know this and are not eager to repeat the mistakes of their predecessors. They will continue to work with and conform to the requirements of the JCP. If they don't, J2EE will be lost and so will IBM's WebSphere and BEA's WebLogic.