n the Java market, “write once, run anywhere” standardization is the carrot and the threat of .NET adoption is the stick. Which is the greater motivator depends on the vendor’s standing in the market. For the leaders, standardization may negate the differentiators that have made their products popular, so their attention may be more focused on competing with Microsoft. The Java vendors playing catch-up, meanwhile, recognize that standardization can level the playing field for their products.
The good news for programmers is that every vendor, regardless of market standing, must first and foremost meet the requirements of its customers (i.e., Java developers). With several major product releases announced by Redmond last fall at its 2003 Professional Developer’s Conference, no Java vendor can risk leaving its users unsatisfied.
The bad news is that the Java platform that developers want?true “write once, run anywhere” interoperability, where one Java tool, plug-in, or API works seamlessly on any Java-based platform or environment?probably will never transpire. Why? Because there’s no competitive advantage in making a product that works just as well as the next guy’s.
In the middle of this standardization vs. commercial competition tug-of-war is the Java Community Process (JCP), the formal Java specifications process that accepts Java Specification Requests (JSRs) and evolves them into functioning APIs through community review. The JCP, which just had its fifth anniversary in December 2003, has the challenge of trying to strike a balance between the two sides. While appeasing the standardization interests is something the JCP has handled well (you can’t argue with the wide adoption of JCP-developed technologies such as J2EE), it’s less successful at accommodating the rapidly evolving business requirements of its members’ Java customers in a timely manner. Processing specification requests takes time, but Java vendors often can’t afford that time. Time-to-market pressures call for immediate solutions, but the JCP is only as agile as the process to which it’s bound.
The recent formation of the Java Tools Community and the vendors that were conspicuously absent from its membership, as well as the joint proposal of three JSRs by IBM and BEA, illustrate how strong a force commerce is in the evolution of Java. Yet, they?along with provisions planned for the next release of the JCP (2.6)?also prove that developer input regarding how to improve Java ultimately takes priority. Everyone seems to recognize that the next great Java API, the one that will facilitate a big leap forward, will emerge from the mind of developer in a Java shop somewhere.
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.
|
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 solution?an 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.”
|
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 proposal?even those based on something that’s already available in a product?is “subject to change according to the whims of the community.”
When Developers Talk, People Listen
All Java vendors ultimately are allies in an ongoing war against a common enemy. The enemy is Microsoft and the prize is enterprise computing market share. Any Java advancements in general are a win for the individual vendors in particular, and the source of Java innovation is the millions of Java developers “in the trenches”. That’s why vendors pay such close attention to their customers’ requirements and work to meet them as quickly as possible?even if they don’t always have the time to submit JSRs for them and wait while the JCP process runs its course.
IBM and BEA didn’t jointly develop their three specs because they enjoy collaborating with their fiercest rivals, they did it because customers urged them to make their jobs easier. Customers prompted the collaboration and the vendors thought enough of the results to propose their solutions to the Java community at large.
The JCP, for its part, also recognizes the value of developer feedback. Among the changes slated for the next version of the JCP (2.6, due out this spring) is making all draft reviews publicly accessible. Presently, you must be a JCP community member to see the first draft of a JSR, and public review isn’t allowed until the third step in the JCP’s four-step process. “For many JSRs, the most valuable feedback comes during public review, which of course is great but it comes relatively late in the life of the JSR,” Kluyt says. As a result, spec leads generally can’t incorporate the feedback into that release.
So don’t assume you’re at the whim of the big players in the Java space to get the functionality you want in your Java products. Remember the innovation flow begins in shops like the one you work in everyday. Vendors will pay attention to your requirements and even act on them?as long as it makes business sense.
