About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
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.
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 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).
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 java.net 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 java.net 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."
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."
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 java.net, 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.
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 jcp.org.
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.
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).
Michael Nascimento Santos manages the JSR
Community on java.net, 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 java.net makes
it very clear that the community drives the process and not just major vendors.
So, everybody wins."
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 jcp.org 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. |
|
