By Susan Mitchell
December 2003 marks the five year anniversary of the Java Community Process
(JCP) program, the formal community-based process for evolving and
maintaining Java technology specifications, Reference Implementations
(RIs), and Technology Compatibility Kits (TCKs). Java technology
emerged whole from the proverbial code soup in 1995 after its
creation by the Green Team of Sun Microsystems. In the ensuing five
years it has evolved into a productive, award-winning entity, thanks
largely to the passionate efforts of the JCP's international Java
developers. In offering a hot house where rapid development could
flourish, the JCP has itself followed an unlikely evolutionary
trajectory of increasing inclusiveness, openness, and transparency.
The JCP Standards Body Criteria: Compromise, Complete Compatibility, Copyright
Sun has staked its future on the promise of Java technology. As Java
technology has proven itself, others are also staking their futures
on it. As of today, about three million developers have fallen in
love with the program language's ability to boost their efficiency
with the ability to Write [an application] Once, [and have it
successfully] Run Anywhere on a wide variety of platforms and
Sun was determined to ensure compatibility of all implementations of Java technology.
During 1997 and 1998, Sun sought a place to set
up Java standardization in the context of a traditional standards
body. Because of his prior experience with standards bodies, Rob
Gingell, now Sun fellow, vice president, chief engineer, and JCP
Chair, served as distant advisor in the quest, but every avenue
proved woefully inadequate.
A first attempt was made at the International Standards Organization
(ISO), where Sun achieved the status of being able to label Java
specifications as ISO standards. However, Sun could see that
standards institutions like ISO, where consensus is required rather
than compromise, progress would be slow in the best of circumstances,
could be deadlocked for political and other reasons, and might
encourage feature-stuffing as a way to acquire consensual votes.
Sun also considered the ECMA International (formerly European
Computer Manufacturers Association) standards body, but it had the
same flawed consensus structure. Moreover, there was no assurance of
completeness in the implementation of a specification; implementations of ECMA
specifications could claim compliance even if just one chapter of a
standard had been implemented, says Onno Kluyt, director of the JCP
Program Management Office (PMO), Sun Microsystems.
Worse yet, neither ISO nor ECMA provided any guarantee that Sun could
retain its Java technology copyright, the important tool
for achieving and protecting compatibility. Traditional standards
bodies aren't interested in copyright and trademark protection, performance
testing, and other activities that are critical for delivering the
properties of a binary standard, says Gingell. Without those
properties, there is no Write Once, Run Anywhere. Binary standards
refer to the ability to take parts that come from different companies
or software writers and put them together and effectively use them."
In searching for a standards body, it became obvious to Gingell that
"nobody in the industry really knows how to operate a binary
standard." Defined in the java[x].* namespace, Java technology is the
only successful binary standard because, according to Gingell,
everyone else appears oblivious to the benefits of focusing on
A Hybrid Standards Group is Born: JCP 1.0
The effort to launch a new standards group began in earnest once the
principals realized traditional standards bodies were not "fit
places" to incubate Java technology, says Kluyt. At the Javitz Center
in New York City, December 1998, Alan Baratz, then president of Sun's
JavaSoft business unit, officially announced the JCP 1.0 program.
Headed up by Jim Mitchell of Sun Labs, the JCP was designed from the
outset with change in mind, and it's the only standards body that
includes a version number.
Employed by Sun at the time, George Paolini was surprised when "the
industry actually embraced the model of the hybrid standards group,
if somewhat begrudgingly with regard to Sun's reserved control over
key components of the platform. To my knowledge, no one company has
done that in the past." He was pleased with how quickly the industry
adopted the JCP jargon. "It seemed almost overnight we were hearing
references to 'JSRs' with customers, press and analysts, as though
the term had been around forever."
While the JCP had endowed spec leads with strong decision-making
powers to encourage rapid development of specifications, all higher
level decisions were made by Sun. The JCP got off to a "reasonably
good start" with what Gingell calls a benevolent dictatorship
structure. At the time, Sun, through the PMO, decided which proposals
were approved, which spec leads were capable, whether a JSR was
complete enough to go final, and so forth. But it wasn't long before
participants complained about Sun's control over the JCP. "And
rightly so," notes Kluyt, who arrived mid-1999 to manage the hot
The success and importance of Java technology depends upon involving
a large part of the industry. That involvement came about, and the
community became so invested in the technology that it became risky
for the players "to rely exclusively on the perhaps momentary
goodwill of somebody who may from time to time or permanently be one
of their competitors," says Gingell. The price of the industry's
continued commitment was that Sun's overt power diminish, enabling
Sun to benefit in more important ways. According to Gingell, Sun was
willing to accept a reduction in authority for two reasons. Allowing
others to participate more fully reduces Sun's obligation to evolve
Java technology in all the markets where it needs to be. Furthermore,
the success of Java technology means that Sun -- along with scores of
other people and organizations -- wins if Java technology wins.
New EC Decision-Making Apparatus: JCP 2.0
George Paolini initially conceived JCP 2.0 to soothe some of Sun's
disgruntled licensees by addressing their fears. He says,
"Essentially they had realized that they were now dependent on a key
technology that was being delivered from Sun. In some cases, these
companies were key competitors to Sun."
A number of structural changes were made to evolve the JCP into a
republic-like structure. "The JCP is very much an exercise in
compromise for everybody, including Sun," says Kluyt. "They got some
of what they wanted and some of it they didn't get. While we all
share a common goal most of the time in our drive for compatibility
and the business success of Java technology, we don't always agree on
how to get there."
Those amendments were formalized June 2000 with the launch of JCP
2.0. Members other than Sun were now permitted to create pieces of
what would become the Java technologies. In addition, the PMO moved
into the role of facilitator, ceding its decision-making authority to
the two newly created Executive Committees (ECs), that included
representatives elected from the JCP membership. One EC oversees JSRs
related to Java 2 Platform, Micro Edition (J2ME) while the other does
the same for Java 2 Platform, Standard Edition (J2SE) and Java 2
Platform, Enterprise Edition (J2EE).
Initially, Paolini chaired both ECs, but he now serves on the
J2SE/J2EE EC as representative of Borland Software, where he is
general manager and vice president for Java Solutions. He reflects,
"When you're managing an organization that is attempting to drive a
singular agenda, and the members are made of representatives from a
couple dozen companies that each have individual agendas, it is a
constant challenge to keep the organization focused."
Rob Gingell, the current JCP chair, believes most EC members feel
they're better off today than they were at the inauguration of the
ECs, though some might prefer Sun's role reduced again. He notes,
"the JCP continues to evolve to respond to the needs of a community
of those who are increasingly as dependent upon Java and its future
as Sun is, and we have to find ways to meet their needs, which are
not always the same things as all the things they might want." When
asked about the industry's desires in terms of further reductions in
Sun's role, he replies, "We're not really contemplating changing much
in that regard; we think we have the minimum authorities consistent
with both protecting the compatibility proposition for everyone and,
as the party who took the risks in creating and offering the
technology, our dependency upon its future."
True Supporter at Siemens
Marquart Franz, currently principal engineer at Siemens Corporate
Technology (CT, the central research and development group of
Siemens) and representative on the J2ME EC, embraced Java technology
in 1995. The technical and economic benefits for developers --
Siemens has 33,000 of 'em! -- and sometimes for manufacturers were
compelling. The mobile phone group was especially taken by the
technology, quickly abandoning proprietary extensions in favor of
standard ones. With his team, Franz actively advocates and supports
Siemens groups in terms of Java technology design, architecture and
implementation, licensing, and standardization.
"We at Corporate Technology are always searching for the best
technology, and it was our belief that Java would have a big impact
on our products. The best way to meet the market is to start a JSR,"
Franz says. Siemens has since led eight expert groups (only Sun and
IBM have led more), participated in countless others, and held a
perfect record for attendance and voting in the EC.
As vice chair of Sun's Java standardization approach with ECMA, Franz
observed Sun struggle with the decision of where to entrust the
standardization of Java technology. He says the JCP has done a "good
job" of uniting the community of invested corporations and
opportunity-seeking developers under one roof. "For developers, it's
accepted that when a JSR is finished, it IS a standard."
Open Source Attains Equal Standing: JCP 2.5
The world changed unexpectedly during the years since the JCP's
founding. Back then, open-source software was simply not done in the
corporate world, Kluyt recalls. Sure, it existed as the output of
university academics or small enterprises, but was not something
companies like IBM or Sun considered a core efficiency. By 2002,
though, that elitist view was thoroughly obsolete. With almost all
high tech companies producing open-source software in one form or
another, the JCP found itself playing catchup in a skirmish with one
of its members, the Apache Software Foundation.
Geir Magnusson Jr, Apache's vice president responsible for
involvement with the JCP, serves as Apache's representative on the
J2SE/J2EE EC. He's also an independent consultant and principal in
the small startup, 4 Quarters, LLC. Magnusson describes Apache as a
membership-based, non-profit corporation that provides
organizational, legal, and financial support for Apache open-source
software projects. "Our efforts are aimed at insuring that the Apache
projects continue to exist beyond the participation of individual
volunteers, to enable contributions of intellectual property and
funds on a sound basis, and to provide a vehicle for limiting legal
exposure while participating in open-source software projects" such
as its web server, "httpd," now running two-thirds of the world's web
sites. "As we support open standards for software development, many
of our members are active in various industry standards groups,"
Sun nominated Apache for one of the original ratified seats on the
J2SE/J2EE EC. "We accepted because of our numerous Java technology
related projects and our interest in implementing and influencing the
standards process in Java technology. We felt it was a good
opportunity to represent the open source view in the JCP. As we like
to say, we try to ensure that there is 'community' in the Java
Community Process," Magnusson says. Apache views the JCP
pragmatically, as just one vehicle for supporting open source
projects. "We are willing to implement specifications, but we also
support software development that solves the same problems as those
specifications but in a different way."
Although the JCP recognizes Apache as a single member in the same
manner as IBM or BEA, many Apache members participate via individual
or corporate involvement. Besides serving on the EC, Apache has been
the host of several open source RIs and codebases for various JSRs,
such as servlets, JSPs, and JSTL. Apache is currently working on
'Geronimo,' which should be the first certified open source
implementation of the J2EE specification.
Apache contributed substantially to the changes spelled out in JCP
2.5 in a successful attempt to resolve numerous legal issues. "Prior
to 2.5, we couldn't legally implement JSRs under our open source
license without having to place unacceptable restrictions on users of
our software beyond the minimal restrictions listed in our license,"
Kluyt wishes the JCP had made the changes earlier, but is confident
they weren't made too late. He says, "The changes we made in JCP 2.5,
especially towards members like Apache and other open source
environments, make it possible for them to fully collaborate in the
process. That folks like Apache and JBoss can now do an open source
implementation of J2EE is a good thing because it drags these
developers into the Java technology."
Individual Participants Flock to the JCP
Apache fought for individuals and open source groups to be admitted
into the JCP as members of equal standing, free of charge, able to
participate fully and build compatible independent implementations.
Until recently, Magnusson notes, "individuals had an anti-reward to
join -- they had to pay an entry fee to volunteer their time and
expertise. Now, they can participate for free, and they get rewarded
in the same way they are rewarded for open source software
Unlike Apache, most open source groups are not legally organized.
Apache feels individuals in those groups should be represented as
well. "We find that on expert groups, the individual contributors
tend to be very motivated because they are doing it for the love of
technology, the recognition, or just the chance to participate with
other like-minded experts, rather than for a paycheck," says
After JCP 2.5 was accepted, individuals began joining the program in
droves. In 2000, the JCP counted a membership of 275, adding over a
hundred the next year, then another hundred the year after that. But
in 2003, the JCP experienced an unprecedented surge in individual
signups. With 700 total members now, nearly one-half are individuals.
"In December 1998, I don't think anyone imagined individuals --
people operating on personal titles and not representing their
employer -- would be making key contributions to the evolution of
some specification," says Kluyt.
O'Reilly author and Gefion Software's president, Hans Bergsten is an
individual member who, because of his passion for software design,
now finds himself involved in five expert groups (EGs 52, 53, 127,
152, 154). His involvement with the servlet spec development
pre-dates the formal JCP. He says, "I was very active on the public
mailing list, answering user questions, suggesting features, and so
on. One day, back in 1998, James Duncan Davidson asked me to join a
private list he used for discussions about the Servlet 2.1 spec, and
I said yes. At the time, I was developing a servlet-based product for
my own company and saw this as a chance to ensure that the new
version of the spec fit my needs."
Bergsten's involvement gathered a natural momentum when he gravitated
toward technologies that interested him. Serving as an expert
represents a full-time job during intense periods and about half-time
at other times, says Bergsten. "I doubt I would be able to take on a
spec lead role, because it takes even more time. However, I believe a
more open process, where the RI and TCK are implemented as open
source and most of the discussion takes place on an open mailing
list, would make it easier for an individual to act as the spec lead."
Despite the significant time commitment, Bergsten finds numerous
reasons to stay involved. "Initially, it was to ensure the specs
evolved in line with my product development needs, but I also like
working together with great minds to solve complex problems. Today,
that's my main motivation. Another reason is that it helps me to
write about the technologies; by being very much involved in their
development, I have the inside scoop."
Bergsten, having worked in the IT industry for over 20 years, most of
those as an architect or systems analyst, and with Java exclusively
since 1997 says, "In most cases, I feel like I have as much influence
over the specs as any EG member from a commercial company. When I'm
in an EG, I am very active, and I don't shy away from saying what I
feel about proposals from others or spending time coming up with
detailed proposals of my own. The way most EGs I've been in work is
that the more effort you put in, the more the other EG members
respect your ideas and are willing to cooperate."
Individual Academics Apply Research
Doug Lea, PhD, teaches in the Computer Science Department, State
University of New York at Oswego. He joined the JCP three years ago
as an individual participant after Tim Lindholm called him to ask,
"Don't you think an academic should be on the JCP EC? Can you think
of any academic besides you with enough name recognition to get
elected?" Having earned a JavaOne "Golden Duke" award for
contributions to the Java platform in 1998, and thanks to his high
profile in running OOPSLA and publishing a couple of programming
texts, Lea was elected. He has served on the J2SE/J2EE EC ever since,
offering what fellow EC members consider to be a more objective, less
commercial, view of reality.
There may be as many as ten other highly active academics in the JCP,
Lea estimates. The program is a great place to put their theories and
research into practice. In fact, some spec leads actively seek out
academic individuals who have relevant, and perhaps esoteric,
expertise. Lea says academics are "the people who know the most and
are usually very happy to share their knowledge."
Lea is delighted with the changes wrought by JCP 2.5, and his JSR 166
Concurrency Utilities is considered one of the posterboys for the
revision. He says, "Everyone is thrilled with our extremely open
process. Our interest list has about 300 people on it. We've provided
API [Application Programming Interface] snapshots-of-the-day. We've
had a preliminary Reference Implementation." The open process works
well for this small area where interested people want a peek at
what's going on. "Less protection was needed because there's no real
commercial interest. It would have been silly to have a closed
process. The important thing is to make the spec very solid, to make
the implementation flawless. The people who are interested enough to
care about this technology, care deeply," says Lea.
Daily Life of Spec Leads and Experts: JCP 2.6
Over time, the program office has noticed that spec leads fall into a
predictable pattern of taking over-long to submit specs for community
review. Help for the bottleneck is on the way in the form of JCP 2.6
(JSR 215). Apparently spec leads worried that at the end of community
review, the EC would vote down a draft that was imperfect. To avoid
such trauma, they polished their draft before community review, then
postponed incorporating feedback until the next version of the spec.
"Most JSRs get the majority of their feedback during public review,
but by that time it was already cast in stone," says Kluyt.
Scheduled for release early 2004, JCP 2.6 encourages spec leads to go
into review earlier, offer the draft to a wider audience, and use the
feedback to help decide on features. Under the revised process, draft
reviews will be visible to anyone with an internet connection,
whether member or not, in hopes of eliciting more input earlier in
the timeline when it can be addressed and the EC ballot will be moved
later in the process.
The program office is pleased that a number of important technologies
such as MIDP are being led by someone other than Sun. Sun exploits
the opportunities available to it, maintaining a huge involvement in
the JCP by attending every single EC meeting, voting on every ballot,
and leading nearly half of the expert groups. But Kluyt wonders why
other companies abdicate their own opportunities so that Sun ends up
creating RIs and TCKs even when Sun isn't spec lead. Kluyt believes
it would be good for the community to gain more experience with the
mechanisms used to achieve compatibility and to grapple with the
difficulties involved in creating those pieces. "If more of the
development is done by others, Sun's role in the community changes
defacto in a natural way," says Kluyt.
To take some of the mystery out of the process, JCP 2.6 will clarify
the requirements of the TCK, improve communications between spec
leads and the Executive Committee, and make the progress of expert groups more transparent to the community.
It will also provide new information about the process of
being a spec lead to help potential candidates understand what is
required and how to navigate the milestones.
The community is coming around, with more and more Java technologies
being developed by others than Sun. At last count 55 different
organizations were leading expert groups. Sun historically has led 42
percent of them and IBM 15 percent. "We expect that the number of
JSRs Sun leads will continue to shrink just because other people are
contributing to the work. That's good for Sun so that Sun doesn't
have to carry the work forward for every part of the industry," says
Fueled by Measurable Success, the JCP Heads into the Future
The decision to create a vendor-neutral standards body to nurture
Java technology was made with some angst, but a retrospective view
endorses it. By June 2003, the SD Times 100 had honored the JCP with an
award in the Standards Bodies & Consortia Category for the program's
ability to "rule Java, despite the proliferation of closed vendors
Since the program began, over 200 JSRs have been submitted to the
JCP, prompting the formation of about 45 new expert groups each year.
Nearly half of the efforts are nearing completion, and about a third
are approved as final, including several major ones:
- in the enterprise space, two versions of the J2EE platform specification
- in the desktop space, one version of the J2SE specification with a
second version nearing completion
- in the wireless space, two versions of the CLDC/MIDP profiles
- in the web services space, more than ten XML based Java platform
specifications, the foundation for interoperable Java Web Services
- for vertical industries, OSS and JAIN APIs
Gingell fully expects the JCP program to continue evolving along with
the platform. Five years from now, he hopes he'll be able to say
"that the community is even more vital and robust, representing an
even larger body of developers than the three million plus we think
we operate for today and that the JCP membership reflects the
importance of Java technology to nearly every arena of computing."
Meanwhile, the industry already recognizes the JCP's outstanding
contribution to the growth of the Java developer community.