Find JSRs
Submit this Search

Ad Banner

JCP 2.6 Clears the Way for a New JSR Community on

by Susan Mitchell
The upgrading of the JCP program to version 2.6 (JCP 2.6) met a tremendous need perceived by Java developers and enthusiasts, JCP members, spec leads, and Executive Committee members. The primary benefit of JCP 2.6 is the transparency it now requires, freeing expert groups to reveal much more about a given Java Specification Request (JSR) as it is being developed. With the mandated increase in transparency, saw an opportunity to support the specification effort by creating a JSR community.
Conception and Implementation

Once upon a time, Daniel Steinberg, now editor-in-chief of, was one of the many people who hammered out Project Montague, the original code name for Launched during JavaOne 2003, is now respected as the source for Java technology collaboration. The Project Montague team "always wanted a JSR community," but the JCP program rules at the time did not permit expert groups to conduct business in a transparent fashion. The release of JCP 2.6 was a watershed moment that enabled the birth of the JSR community on
Daniel Steinberg
Onno Kluyt
Aaron Williams  
Michael Santos
"As soon as I heard about JCP 2.6, I realized that a JSR community would be allowable, and I wanted to make sure that they happened on," says Steinberg. He quickly reached out to numerous people who were ready to help implement the concept. "I exchanged email with Doug Lea [on the JCP Executive Committee] after seeing a panel discussion at JavaOne 2003. I emailed JCP Chair, Onno Kluyt and finally met with him last November at ApacheCon and followed up with Aaron Williams, JCP PMO Manager. I had conversations with Michael Nascimento Santos about him leading such a community. And then there was the long process of making sure everything was done correctly. This phase consisted of a lot of hard work being done by our site producer Sarah Breen and the product manager Christian Cheline working with Aaron, Onno, and Michael."

When it comes to Java technology experience and interest, Santos is well credentialed. At the time he was invited to lead the fledgling JSR community, Santos was involved with and helped coordinate SouJava, one of the largest Brazilian Java user groups (JUGs). He is a Sun Certified Programmer for the Java 2 Platform 1.4, a Sun Certified Web Component Developer for J2EE, and a Sun Certified Mobile Application Developer. Santos has signed a JSPA and contributes to the JCP as an individual expert on JSR 207 Process Definition for Java and JSR 250 Common Annotations forthe Java Platform.
In his other life, Santos is a senior technical consultant for Summa Technologies do Brasil, which was awarded the Duke's Choice Award by Sun Microsystems for "extreme innovation" of Java technology in 2004. Santos was "more than glad" to accept the responsibilities of JSR community manager.
Because JSR information can be sensitive, some may wonder how much insight Santos has into projects hosted by the JSR community. "The only way I can get unrestricted access to a project is if one of the project owners makes me a project owner. Besides knowing who the project owners are, the only thing I am able to access for all projects is the public description, message from owner, and public/private parent project and status," says Santos. Project owners can limit how much insight he has into their projects, "as long as there's some acceptable degree of transparency." A project can maintain appropriate transparency when its owner takes at least one of the following actions:
  • keeps a mailing list for general public discussion
  • sends frequent announcements regarding issues under discussion and currently proposed solutions
  • uses issuezilla to openly provide corrections or suggestions to the spec
  • makes RI code freely available
  • makes TCK code freely available
Santos' privileges regarding regular projects such as JSRs allow him to initially approve/reject a project or to re-parent one anytime (which doesn't affect end users). He can also access management projects and change anything on the JSR community home page at any time.

The JSR community was created to help JSRs achieve maximum transparency and openness, as mandated by JCP 2.6. Currently, although a draft release through the JCP program normally includes a feedback alias, only the expert group sees that feedback, leaving respondents unaware of each other's contributions. But if a group wants the best output possible, they'll prefer informed input. By leveraging infrastructure, an expert group can get the Java community to participate in the process more easily.
For example, an expert group can get feedback early through public mailing lists where they can publish decisions or even unresolved issues and get more people to participate in them. Moreover, in a group discussion, the expert group can discern more easily whether a feature is important to just the sole individual who suggested it or to the number of people who seconded his request. In this way, someone on the mailing list can offer an opinion, giving the rest of the community the opportunity to voice their agreement or not, providing the group with a broad sense of what a plurality of people really think.
The tools available for the JSR community on complement those hosted by the JCP program on To satisfy the JCP 2.6 requirement of creating a JSR transparently, spec leads will certainly want to equip themselves with the following essential tools and services now at
  • file sharing for distributing releases
  • mechanism for granting access to open-source reference
    implementations and TCKs
  • source code repository
  • version control of the specification, Reference Implementation
    (RI), and TCK
  • issue tracker organizes posted notices about specification
    decisions, bugs, and mistakes
  • public and private mailing lists, forums, announcements,
    and news groups
Public mailing lists are especially useful in that they give subscribers the opportunity to comment while offering insights into the topics under debate by an expert group, updated spec status, and dates for when drafts will be available. "We give complete freedom to the expert groups so they can use whatever they want from, to the degree they want," says Santos. Some groups may feel it's better to conduct most discussions privately and then post to the public mailing list once the discussion has matured. Or they may be concerned about protecting intellectual property or copyrighted material in general. Expert groups can restrict access so that only they have access to the Concurrent Versioning System (CVS), issue tracker, forums and other resources when necessary. And when it makes sense, they can offer these facilities to the general audience.
"We don't force expert groups to disclose any information they think shouldn't be made public. We want to make getting in contact with the community easier," Santos says.
Joining Up

Aside from time, there is no cost for joining the JSR community. Most people do not join the community directly partly because they don't have to belong to the JSR community to have access to its resources. Those who do join typically get involved with specific sub-projects of the JSRs they are interested in. Others might join to promote the JSR community needs as a whole and to improve its operation. JCP spec leads, however, ought to jump into the JSR community with both feet. The upside is huge in terms of efficiencies gained and the likelihood of ending up with a stronger specification, RI, and TCK.
"The current community goal is to get more JSRs to join so we can discuss and define the process and governance at a community level," says Santos. "We want people to tell us what they think about the JCP program and the way the JSRs are being conducted at, so everyone can do a better job and get better results."
An expert group that wants to join the community follows the normal project submission process, where a spec lead creates a username, proposes a project, and explains that it is a public project for a JSR. Santos approves the project, helps organize the project in a way that meets the specific goals, and announces to the community that the expert group has joined the JSR community. When a new project joins, Steinberg typically announces it in his today blog on the main page of
After a JSR has been approved as final by the JCP program, the expert group can continue to collect community input in preparation for the next version. Any mistakes can be recorded there, leading to what might become a maintenance review.
Using Tools

Ed Burns
Sun staff engineer Ed Burns is the co-spec lead for JSR 252, and the JSR252 project page. Burns heard about the JSR community through the grapevine, that is, from a fellow spec lead who is now a satisfied JSR community member. "As a specification lead for the Java Server Faces expert group, I think is very well suited to satisfying section 2.16 of the JCP 2.6 program, which calls for transparency in expert group operations."
Burns planned to use features such as their issue tracker and file-sharing section to allow for more transparency. "Practically speaking, the source code repository and the issue tracker are two things that we would have to have done on our own if it weren't for having these available to the JSR community on"
Burns is still trying to figure out whether such transparency actually increases the quality of the specification by eliciting more and better user feedback. "That's what we're hoping for, and it's too early to tell that," he says.
PMO Perspective

Liz Kiener, the JSR program manager for the JCP Program Management Office (PMO) is an important person for a spec lead to know. She has eyed with interest "because it provided tools that would be useful for JCP program spec leads and expert groups. When the JSR community began, that was the trigger that I needed to be involved. It's a very good collaboration tool for spec leads."
By joining the JSR community, Kiener wanted to be introduced to participants as a way of letting spec leads know they can contact her with questions if they need help going through the JCP program process. In her role with the JCP, Kiener facilitates collaboration between the spec leads of related JSRs such as JSR 176 and Tiger, through events including JCP program training sessions, and by JCP updates and the PMO news. "I provide an environment similar to a mentor program where seasoned spec leads give advice to new and future spec leads on how to go through the process and solve typical problems. This saves new spec leads time -- they don't have to reinvent the wheel," says Kiener.
The JCP PMO and JSR community look forward to their close collaboration. Kiener now belongs to the JSR community and can log into it. "We link to each other's sites. I note in my JCP program training presentations that the JSR community is available on," she says.
Peering Into the Crystal Ball

The opportunities for organized transparency that have opened up through the JSR community are impressive, and the price is right. In a nutshell, the JSR community offers spec leads the essential tools and services for making the development of JSRs more efficient and transparent: public and private mailing lists, forums, announcements, and news groups, file sharing, source code repository, version control, and issue tracking.
Now is a great time for JCP spec leads, experts, and members to step into the JSR community and step up to shape its future. Members are always welcome to suggest improvements, and Burns, for one, hopes the community will have access to more collaborative tools in the future. On his wish list are a shared white board information space that everyone can access during a virtual expert group meeting and live public and private chat rooms for each JSR project.
Santos has plans of his own, to "promote integration between members and give them even more of an active voice soon" by making the JSR community home page a source of news about the JCP, JSRs, and related subjects. He will also start a general jsr-community mailing list for project owners in order to keep them informed of the rules, foster discussion of pertinent issues, and permit them to drive the community's evolution.