CNET también está disponible en español.

Ir a español

Don't show this again

Tech Industry

Commentary: Java needs a chief architect

Although proposed changes to the JCP should make it more open and accountable, Java development and licensing still needs a leader to tie its many standards efforts into a cohesive whole.

Commentary: Java needs a chief architect
By Forrester Research
Special to CNET
June 11, 2003, 12:15PM PT

By Randy Heffner, Research Leader

Recently proposed changes to the Java Community Process include important steps to make the JCP more open and accountable, but Java's fundamental issue remains its lack of a chief architect to tie the many diverse Java standards efforts into a cohesive whole.

This disorganization leads to a notable degree of uncertainty over which Java Specification Requests (JSRs) will actually result in standards. Application architects and IT shops should plan lightly on any JSR coming to fruition until it is in the final stages of development and adoption. Once the JCP improvements envisioned by JSR 215 are implemented, Java architects should use the increased process visibility to enhance their architectural planning processes.

JSR 215 is targeted for completion in late 2003 and envisions nine adjustments to the JCP. All nine changes are useful, but three of them are clearly more important than the others:

• Earlier disclosure of licensing terms. Each JSR approval includes the licensing terms and conditions for the reference implementation and technology compatibility kit produced by the JSR (but not dollar amounts of any license fees). The executive committee receives an early look at these licensing terms, and this proposal would move toward earlier and broader disclosure, which would give the Java community a more complete picture of the likely limitations to and the impact of a particular Java standard. As an example, it is critical for a mobile phone company that sells millions of phones to know whether a given Java 2 Micro Edition (J2ME) JSR will be licensed per unit.

• Earlier public review. Currently, early drafts of a JSR are reviewed confidentially among JCP members before they are available for public review. This proposal would make early drafts available to the public, allowing greater and timelier public scrutiny and providing architects greater lead time for planning responses to upcoming JSRs.

• Regular status reporting. Currently, the only time that the public knows whether work on a JSR is proceeding is when the JSR advances to the next stage of the process, which in some cases has been a span of two or more years. This proposal would implement status reporting for JSRs, making it more clear to the public whether work on a given JSR has gone dormant and enabling architects to adjust plans as appropriate.

The general theme of JSR 215 is to further open the Java process to more watchers, without bogging down the process by adding more

Related story

The new Java Research License aims
to strike the right balance between
unfettered investigation and legal
and technological protection of Java.

decisionmakers--and Giga (a Forrester subsidiary) views this as a positive. Greater visibility enables more rapid identification of instances in which a Java vendor attempts to directly standardize features of existing products. It also helps maintain community involvement in complex and long-running JSRs that are developing new technology areas for which there is little prior art.

If implemented, the proposed changes would be important improvements that strengthen the process for developing Java standards, reinforcing Giga's position that the JCP, for all intents and purposes, is an open multi-vendor standards process. Note that, contrary to popular misconception, Sun does not own all of Java--each "JSR spec lead" owns the licensing rights to the JSRs it leads. Sun is the spec lead on only about half of all the JSRs that flow through the JCP, although it is spec lead on a higher percentage of the JSRs that are core to J2ME, Java 2 Standard Edition (J2SE) and Java 2 Enterprise Edition (J2EE).

Still, in competing with the Microsoft platform, Java's biggest disadvantage is not having a unified and efficient way to bring the diverse set of Java community plans, ideas and goals together into a coherent plan that explains the necessity of and relationships between the many different JSRs. Although this weakness is not fatal to the Java standards process, over time it does make it slower and more difficult to build and retain Java's portability and vendor leverage, and it hampers IT's ability to plan strategically for future Java deployments.

It would be a fatal weakness if, as Java vendors compete for market share both among themselves and against Microsoft, the need for innovation combined with the slowness of the standards process and the lack of a coherent direction resulted in a preponderance of proprietary features over standard features in Java implementations. However, Java standards such as J2EE already provide a sufficient base for implementation of core business logic that, even as the pressure for proprietary extensions continues and grows, a substantive portion of an enterprise application will still be able to benefit from Java standards.

Until a JSR is well advanced in its development, Java architects should not stake large bets on its eventual adoption. However, JSR 215's improved process visibility will provide greater opportunity for architects to apply design concepts that are explored by a JSR in order to improve today's designs and to build architectures that can adapt more readily to possible future Java developments.

© 2003, Giga Research, a wholly owned subsidiary of Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.