IBM and Borland: JTC No-shows
How do Java vendors, who all advocate the proliferation of Java as well as its continued standardization, reconcile their support for "write once, run anywhere" with their natural commercial inclination toward "write once (with our tools), run anywhere (on our platform)." What's easiest for the Java developer isn't necessarily what's most desirable for the Java vendor.
For example, IBM and Borland weren't involved in the JTC, a group that includes such Java heavyweights as Sun and BEA. The JTC's mission is to raise awareness in and provide input to the JCP for tool interoperability issues in Java standards. Why wouldn't IBM and Borland want to be involved in a program that seems to promote greater ease of use and choice for developers at design time? Because each vendor believes it already has a solution for Java tool interoperability.
|IBM and Borland each believes it already has a solution for Java tool interoperability. |
"We're putting our efforts with tools around Eclipse," explains Rod Smith, Vice President of Internet Emerging Technologies for IBM's Internet Group. "We're looking to spin off Eclipse, and it can then decide for itself at that point [whether or not to join the JTC]."
Eclipse is an increasingly popular open-source project developed by IBM to be an extensible IDE that can serve as a universal tool platform. IBM is betting on the adoption of Eclipse as the Java tool interoperability solutionan outcome that would render the JTC practically unnecessary.
Borland already has the market leading Java IDE, JBuilder, which boasts more than 700 plug-ins. Would Borland continue to hold its IDE market leadership if all these plug-ins suddenly worked as well with BEA's or Sun's IDEs? Maybe, but why chance it when you're outselling your competitors?
So even as developers may want across-the-board standardization, leaving vendors to compete on features, no vendor is going to relinquish a market lead for the sake of a programming ideal that offers no monetary reward.
IBM and BEA's Joint JSR Submission
The JCP isn't structured for agile responses to business requirements, which is why vendors sometimes take matters into their own hands with an "implement first, standardize later" approach. Once they've solved their customers' problems, they then determine whether that particular solution would be beneficial to the Java community at large.
Such was the case when BEA and IBM submitted three J2EE JSRs to the JCP after they had already developed and implemented these specifications for their customers. While acknowledging the importance of taking different opinions into account for the benefit of the Java community as a whole, BEA Vice President and General Manager, Byron Sebastian, stresses that "it's important for the JCP to move faster."
|When it comes to keeping customers happy, the Java community can wait. |
IBM and BEA customers, many of whom have both vendors' products in their environments, needed a solution for the integration points between the two. IBM and BEA listened, recognized the customer need, and most likely heard an implied "and that .NET platform looks kind of interesting." In their case, implementation took place before the proposal of the JSRs, because the customer requirements called for immediate action. And when it comes to keeping customers happy, the Java community can wait.
Because IBM and BEA are the two biggest players in the Java application server space, some viewed their joint specification development outside the JCP as circumventing the process and freezing other app server vendors out. Sebastian counters that their approach led to higher quality JSRs. "BEA and IBM did a lot more homework upfront to present a more mature, proven request," he said.
From the JCP's view, how a JSR came to them isn't their concern. In fact, although less common than developing a JSR from scratch within the JCP, the "implement first, standardize later" approach has been accepted throughout the JCP's history. "No matter what happened before the JSR was submitted," explains Onno Kluyt, director of the JCP Program Office, "once it's submitted, then as a community we have to agree upon the landscape that the API addresses."
Kluyt acknowledges the potential for JCP members to try and push an existing, product-specific approach through the process as a JSR, but points out that all members understand that every proposaleven those based on something that's already available in a productis "subject to change according to the whims of the community."