| "Sun is discussing a revised version of the Java Community Process (dubbed JCP 2.0) that will allow greater freedom over the control of Java." |
In the few short years since its inception, the Java programming language and its associated APIs have gone from being a small collection of classes for primitive graphical and network programming to a large set of APIs for distributed systems, enterprise development, advanced GUI design, and much more. There are now APIs for graphics and sound programming, cryptography, CORBA, servlets, and they cover such a broad range of other topics that we’ve seen an explosion in the number of new classes being incorporated into the core API and associated Java extensions (the javax.* packages).
This growth has been an important part of the maturation process of Java rather than trying to be all things to all people, Java started out slowly and has been gradually improved upon over the years. How many developers using the Java API have given serious thought to who designs these APIs? How many people have even thought they could suggest a better way of doing things or dreamed of designing an entirely new API for a specialized task? The answer is, surprisingly, a great number of people. So much so, that in late 1998, Sun Microsystems heeded the call for more input into the specification of Java APIs and established the Java Community Process (JCP), an open and transparent mechanism for Java licensees to propose new specifications, and for the public at large (the Java development community who will ultimately use them) to pass judgment and suggest revisions.
Over the past few years, Sun has also been on the receiving end of criticism by Java licensees, the media, and developers over the lack of standardization of the Java language, and the openness of control over the direction of Java. However, as you’ll see as you learn more about the Java Community Process, the system that’s been put in place is actually quite an efficient one for working through new API specifications, as well as changes to existing ones. The sentiment of the Java community has slowly but noticeably shifted away from a determination to have Java standardized, due in large measure to the success of the Java Community Process. Both Java licensees and Java developers have an equal stake in the success of the JCP and the ability, perhaps even the responsibility, to contribute to it.
The Java Community Process in a Nutshell
You probably remember back in those distant days at school, learning about how a bill becomes a law (don’t worry, there aren’t any tests here!). Well, in many ways the Java Community Process is similar. The JCP defines how an idea for changes to the Java API becomes a specification request, is fleshed out into a specification, and is then reviewed and refined, until it is implemented. Let’s look at how this process works.
 |
The first stage is coming up with an idea, which isn’t too difficult. There are many ways in which Java can be improved and better meet the needs of software developers. Perhaps it’s a new distributed systems technology, or a new feature like assertions or better arithmetic support. From this idea comes a Java Specification Request (JSR), which is open to public scrutiny by developers and posted on the JCP site. This is a great place for developers to visit periodically as well you’ll get advanced insight into new ideas for improving the language. For the list of JSRs, see Resources below.
Not every JSR will be selected, of course. Sometimes a specification may overlap with an existing specification or may not be appropriate. For a minimum of seven days, and a maximum of thirty, the JSR will be available for review by members of the public. Providing everything runs smoothly and the specification has merit, it will proceed to the next step, which involves the production of a draft specification. In order to develop a specification, an expert group will be assembled, with representatives from Java licensees and other JCP participants. This group produces a reference implementation, which is a prototype and proves that the concept is viable. They are also responsible for defining a compatibility test suite to ensure that any specification implementation meets a series of requirements. Finally, after experts meet and work through the specification, a draft is released. This is then opened to scrutiny from other JCP participants (for a minimum of thirty days), and later the general public (again for a minimum of thirty days).
After a suitable review time, and relevant feedback is acted upon, the specification is given its first public release (moving away from a draft stage). If any defects are uncovered, it will be revised, and then move on to the final release. Once released, however, the work doesn’t end there. Further maintenance may take place, and the specification may be modified at a later time. Like any software development project, maintenance forms an import part of the process life-cycle.
Participating in the Java Community Process
There are two ways that one can participate in the Java Community Process. The public does, of course, get to participate very heavily. They can:
- review and comment on Java Specification Requests
- receive advance notice of proposals to change Java, by reading JSRs from the JCP site
- review and comment on public drafts of specifications
- gain access to public releases of specifications
This is important, as the JCP makes the development of any changes to Java completely transparent and gives the developer community who will use it a voice. This will help to create a more-rounded Java, which better suits those who will construct software with it. If, however, you want to control the process and submit your own JSRs, the story is a little different.
To start the ball rolling and submit your own JSR, or to participate in the expert group of an existing JSR, a company or organization must sign the Java Specification Participant Agreement (JSPA). This is where things can get a little costly. If your company is already a fee-paying Java licensee, there is no additional cost. Otherwise, the fee for participation for a company is $5000, and for an educational or non-profit organization, $2000. In Sun’s defense, the cost of the Java Community Process administration must be fairly considerable, but the high fees will be frustrating for smaller companies and organizations such as colleges and universities.
Keeping the Java Community Process Running Smoothly
As any professional software developer would know, some projects succeed and some projects fail. Poor management has been the death of incalculable projects, particularly when collaboration from two or more organizations is required. So for the Java Community Process to run smoothly, independent auditing at key milestones throughout the life-cycle of specification development takes place. This allows problems to be diagnosed early and corrective action taken.
The auditor has an important role to play, and as soon as an expert group is formed to work on a specification, the first milestone audit takes place. The next occurs when the draft specification is ready for release to JCP participants, then again when member review is complete, and yet again when the public draft review is concluded. In addition, a final auditing report is produced at the conclusion of the process, and it’s released publicly. This also helps to ensure that the JCP is open to independent scrutiny and is more transparent.
What Types of Specifications Are Under Development?
There are all sorts of specifications being proposed and worked upon. At the time of this writing, there were specification requests for implementing assertions (a highly voted feature request in the Java Bug Parade), for non-blocking I/O, the next version of JDBC, for real-time Java, logging, and much more. There’s even a specification to determine what goes into the next version of Java (after Kestrel) codenamed Merlin, which will ship in 2001. There’s a treasure trove of information that, sadly, not all developers are aware of. All developers can benefit with a little advance warning of API developments, and it’s important also that the Java programming community contribute and have their say.
Changes to the Java Community Process
Although the full details have yet to be released, Sun is discussing a revised version of the Java Community Process (dubbed JCP 2.0) that will allow greater freedom over the control of Java, and allow groups other than Sun Microsystems to be formed to work on changes to Java, as well giving licensees the power to release specifications and prototypes to the public at an earlier stage than was previously possible. This shows the trend within Sun to relax control over the direction of Java, and open up the process to the development community which is good for Sun, for licensees, and us Java programmers. With such changes, there may never even be a need for standardization, and a reconciliation between Sun and big licensees like IBM may be reached.
Summary
The Java Community Process provides all developers, whether licensees, paying JCP participants, or the average programmer working for a living, to contribute to and shape the future of Java. As we all have an interest in the success of this programming language and in improving it to suit our needs, it’s up to every Java developer to review new changes and to offer suggestions. The JCP is also a handy way to keep up-to-date with new changes to Java before they are released, as well as a great way to impress colleagues with your predictions on the future of Java “Yes there will be a new version of JDBC, and I think it will have features like ….” For further information on the Java Community Process, see the URLs listed in the Resource section below.Resources
Java Community Process site, http://java.sun.com/a boutJava/communityprocess/
Java Specification Request (JSR) list, http://java.s un.com/aboutJava/communityprocess/jsr.html
Public review of specification drafts, http://jav a.sun.com/aboutJava/communityprocess/review.html
About the Author
David Reilly is a software engineer and freelance technical writer living in Australia. A Sun Certified Java 1.1 Programmer, his research interests include the Java programming language, networking & distributed systems, and software agents. He can be reached via e-mail at java@davidreilly.com, or through personal Web site.
