Find JSRs
Submit this Search

Ad Banner

Happy First Anniversary: The Open Window of
the JCP Program Version 2.6 Beckons Participants

by Susan Mitchell
Over the past year, the Java Community Process (JCP) program has enjoyed success as never before, with 90 percent of members and nearly 60 percent of non-members reporting their satisfaction with the JCP program. Thanks to the new JCP program, version 2.6, launched March 2004, the community is experiencing a major culture shift in terms of openness and efficiency.
The new rules, developed by the JCP program Executive Committee (EC) under JSR 215 , promote the notion that less is more. Growing numbers of people agree that less shielding of expert groups from community involvement and a shorter time between review periods and votes by the EC will make the process smoother, easier, and better. Both members and non-members are perceiving that the JCP program is open to their feedback and willing to make expert group (EG) work more transparent.
Java Specification Requests (JSRs) that were started in the last year illustrate the benefits of JCP 2.6. For example, JSR 270, the 6.0 version of Java 2 Platform Standard Edition (J2SE), code-named Mustang, will take advantage of the improvements introduced by JCP 2.6, related to transparency and efficiency. As will co-spec leads Volker Bauche of Siemens and Jari Lansio of Nokia, for JSR 228, Information Module Profile - Next Generation. And Ed Burns, co-spec lead for JSR 252, JavaServer Faces 1.2, will leverage collaborative tools for transparency and expects his project to complete in less than a year.
JCP version 2.6 was expected to meet several specific objectives of increased efficiency, transparency, participation, and quality, benefiting everyone associated with the JCP program effort. Many of these expectations have already been met; some will require more time before they can be accurately assessed. However, it is already clear that all sorts of Java technology community participants are pleased with the ways JCP 2.6 benefits them.
JSR Lifecycle Efficiency

Prior to JCP 2.6, JSRs would spend an average of nine months before being introduced to the community for review. That may be an optimal gestation period for a human baby, but not nearly fast enough to keep pace with market demands. It was hoped that version 2.6 changes – the EC no longer votes after the first review period renamed Early Draft Review (EDR), but delays their vote until the second review period, Public Review (PR), and expands the review audience to include the public at both EDR and PR – would help expert groups feel comfortable submitting JSRs for review earlier in the process and to a wider audience, potentially trimming the time before the first review to six months.
The specification always filtered out to the public eventually, but now spec leads are encouraged to air their open issues and submit JSRs to EDR for public scrutiny earlier in the game, reducing the fear of reprisals from the EC at this stage. The best scenario has spec leads promptly addressing all pertinent comments and suggestions that come their way, using every opportunity to improve the specification and raise its chances of wide adoption.
Under prior versions of the JCP progam, spec leads were concerned about going to the review milestones (when the EC would vote) without having fully thought through every open issue, so they tended to nail down proposed solutions early on. When everyone, including the public had made suggestions, those were frequently relegated to a wish list of future version enhancements. Now the hope is that at least within the first six months of a JSR's beginning, a first draft will be made available to the public through EDR for review and comment.
Volker Bauche
Volker Bauche co-leads JSR 228 Information Module Profile - Next Generation, with Jari Lansio of Nokia. Both were "pleased that the new version (JCP 2.6) came to life" and migrated the JSR to JCP 2.6. A senior software technologist with Siemens Mobile, Volker sees the wisdom of this strategy. "Having the possibility of presenting the spec to the public so early (using the early draft review) can help to find any ambiguity or something much earlier, so the risk of having the need of serious changes in the RI/TCK implementation in a late state (i.e., after public review) is much smaller."
Because typical JSRs have an 18-month average life cycle, the process will need to be monitored for a few cycles to clearly assess where the efficiencies have been made. It appears that the total lifecycle of JSRs is shortening, as is the period between when a JSR starts and when it goes to EDR. It used to take an average of 200 days for JSRs to get to this point. Based on preliminary data, it is now taking approximately 125 days for JSRs to get to EDR. Very few JSRs that started under 2.6 have gone into EDR, but the trend is encouraging. "JSRs are getting to the first review period earlier, giving the public access to the JSR earlier, and enabling the JSR to get to market faster," says Aaron Williams, manager of the JCP program management office (PMO).
Transparency of JSR Issues and Drafts

Ed Burns
A key outcome for JCP 2.6 was for expert groups to operate with more transparency, and indeed they have. JSRs initiated under 2.6 are required to include a transparency plan. The plan can be a simple paragraph such as the one drafted by the co-spec leads Ed Burns and Roger Kitain of Sun Microsystems for JSR 252 JavaServer Faces 1.2: "We will leverage the collaborative tools provided by the infrastructure[, where] we will have a public issue tracker [. . . P]rivate issues will be handled with a separate EG-private issue tracker. We will have an EG-private mailing list, and we will have a monitored public discussion forum as well. . . . We will leverage the Early Draft feature of JCP 2.6 to allow the public to see the spec in progress." A spec lead can communicate using whatever tools he or she prefers – blog, wiki, RSS feed, their community webpage, and so forth – in order to help the community glimpse what is happening at various stages in the life of a JSR.
The general wording of the transparency requirement allows spec leads like Ed to "run with it within the bounds of what our management would allow." They put their code on using the Java distribution license (JDL) and the Java research license (JRL). The JRL and JDL are simplifed alternatives to the Sun Community Source License (SCSL) – the JRL can be used for research and to experiment with changes to the code base. However, if it's distributed or used internally, developers will need to switch to the JDL license. He says, "This has been a real big deal because people have been able to find bugs and get greater clarity on exactly what is going on."
Scott Stark
JCP program member Scott Stark, who is chief technology officer of JBoss, remarks that "The improved visibility was a nice change." The transparency plan requirement does two things. For one, it forces the spec lead to think ahead. A plan also gives the EC insights into what the spec lead intends to do, so that later in the process the EC can check whether the spec lead made good on the intention. If a spec lead doesn't provide the promised level of transparency, the PMO or EC can follow up and encourage the spec lead to do the right thing. There's always the not-so-subtle pressure of knowing EC members can vote against a JSR that does not live up to its own plan.
The JCP participants have always worked hard to live up to the process requirements, however, and the transparency plans are no different. Spec leads and expert groups are fulfilling their transparency commitments. Aaron says, "I think EC members have been pleased with the transparency plans that have come through so far. We're already seeing spec leads and JSRs that are providing more access to their information earlier on in the process, and that's essential to fulfilling the goals of JCP 2.6."
New Participation at All Levels

In addition to the goals of JC 2.6 to make the process more transparent and efficient, increased participation and quality were two other constant goals. Participation relates to (1) the JCP's continued interest in attracting leaders and innovators of every market segment, (2) service within the community, and (3) involvement in review cycles.
Transparency encourages public participants like Jacob Hookom to ramp up their level of commitment. Jacob saw the JSR 252 project on, and he submitted his own implementation of the written expression language to the spec leads, who liked what they saw. They worked with Jacob until he got all the tests working, then they accepted him as a full committer – someone trusted to access the source code repository and willing to help augment and maintain the test suite as they develop code. Ultimately, Jacob joined the JCP program as an individual and became a full-fledged member of the expert group.
The JCP continues to attract the movers and shakers among Java developers, architects, and executives. As more organizations and individuals join the community, members like Jacob are challenged to step up a rung in their level of commitment and service, and JCP 2.6 has further encouraged this investment by the entire community.
At the end of 2004, Sun was the spec lead for about one-third of the active JSRs (those that were not completed, withdrawn, or rejected), but had completed more than twice the number of JSRs as the rest of the community. "There is no question that Sun has historically borne a greater burden in terms of completing and participating in JSRs compared to the rest of the community. The PMO loves to see other members of the community step up and participate and invest in the work of the JCP program, and JCP 2.6 has encouraged more active participation," says Aaron.
Scott Stark notes that he now feels "more involved" under JCP 2.6, and he hopes to have the chance to comment on JSRs. JBoss recently was elected to a position on the EC, the top level of community participation that starts with members, moves up to experts, continues to spec lead, then peaks at EC member.
The public can participate without becoming a JCP member and the JCP program wants them to play their critical role in public review cycles. Opening all review cycles to the public, moving review cycles earlier and increasing transparency into the development process has already elicited more community and public participation. "Spec leads who have gone through the EDR have already reported an increase in response from the public with regards to their spec – questions, ideas, thoughts – and that's really what we were hoping for with JCP 2.6," says Aaron.
High Quality Deliverables

It makes sense that if more community members and public participants get involved in the activities of the JCP and develop or comment on JSRs in progress, then naturally the JSRs will increase in quality and the deployed spec will enjoy broader adoption. A big aspect of quality involves the TCK (Technology Compatibility Kit), that is required of all JSRs. The TCK is the suite of tests, tools, and documentation that allows an implementor of a specification to determine if their implementation is compliant with that specification.
TCK development is not exhaustively documented, but is best learned by doing. Today Sun still does more than 80 percent of the TCKs that come out of the community. The complexity causes many spec leads to delegate this task to Sun, even though Sun tries to enable engineers to develop their own TCKs by providing tools, including a test harness that is freely available to spec leads and available on
Aaron Williams
With JCP 2.6, spec leads are now required to submit a TCK plan with their JSR to make it easier for the EC to help them generate a quality TCK. "Asking them questions and requiring them to produce documentation early on about their plan for producing a TCK will certainly help them get their heads around how big the commitment is. It's not something they can put off until the very end and then find all the resources to pull it together," says Aaron. But even if you are careful not to underestimate a TCK implementation, Volker warns that "it will always take you twice the time you think it will."
The documentation provided on preparing TCKs covers the basics of how to do it, what to test for, what's important, and what's not. It remains to be seen whether spec leads will pick it up and run with it. So far, the PMO is pleased that the documentation is being used, with a commensurate uptick in the number of companies that are creating their own TCKs.
About 30 JSRs have begun since the launch of 2.6. Most of those have not yet reached the stage when TCKs are typically written. As a result, it's hard to say whether those spec leads will produce their own TCK or not. It is also far too early to know whether the TCKs that emerge will exhibit a higher quality, delivering consistent results across platforms to those using it to test their applications on various implementations of the related JSR.
New and Updated Tools

JCP 2.6 brought not only high expectations for enhancing participation, transparency, efficiency, and quality, but the tools to make good on them as well. The Spec Lead Guide, observer aliases, and community webpages are "useful tools, and they work well," says Volker.
The Spec Lead Guide included significant updates, to address the transparency plan, the TCK documentation, and other requirements of JCP 2.6. "It has all the information spec leads need to be successful," says Aaron.
As another means of transparency, the PMO has set up observer aliases that are available to the spec leads for communicating to an audience beyond just the expert group.
The PMO provides spec leads with two separate, password-protected webpages. The expert group page has always been available for the spec lead to use to assemble contact information, uploading files for the expert group to access, and communicating within the group. The PMO has begun providing a similar page where a spec lead can communicate with the entire JCP program membership by uploading update files and a list of open issues. A spec lead can feel secure that what is published on these pages is covered under the JCP program membership legal agreement governing intellectual property, the Java Specification Participation Agreement (JSPA).
A Positive Direction

Michael Nascimento Santos manages the JSR Community on, where spec leads have access to even more tools, enabling their JSRs to achieve maximum transparency and openness. "The changes introduced by JCP 2.6 are really positive for the community and the process itself. Earlier feedback, open discussions and all transparency-related actions promoted by this new version will greatly improve the way specifications are developed and it is likely it will lead to better APIs and definitions," says Michael. "The fact that JSRs are now allowed by the process to have a public project at a place such as the JSR Community at makes it very clear that the community drives the process and not just major vendors. So, everybody wins."
Michael Santos
JCP 2.6 favors everyone involved in the JCP program – the public participants, community members, experts, spec leads, EC members, and the PMO. If JSR lifecycles shorten, consumers may even benefit by virtue of the more rapid speed to market of products that incorporate the newest technology.
In the months after 2.6 went into effect, Aaron observed that the feedback he received was positive. "We've definitely improved the lives of participants from each of those categories. I haven't received complaints about the changes made for 2.6, whereas I have seen email from spec leads and even public participants saying, 'Thank you. I appreciate the fact that I can get this spec earlier. I appreciate the tools that you are providing us now to make this easier.'"
The October 2004 results of a survey conducted by the PMO on support this feedback. As the JCP program evolves, growing numbers of members are impressed with the JCP's responsiveness and receptiveness as well as with the ease of working with the program office. And the vast majority (96 percent) of the members affirm their belief that the JCP program is vital to the future of Java technology development. At the one year anniversary milestone of JCP 2.6, this simply confirms what many already believed.