Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Java Standardization vs. Competition: Developer Input Carries the Most Weight

Although what's easiest for the Java developer isn't necessarily what's most desirable for the Java vendors, they recognize that the next great Java API will emerge from the mind of a developer.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap