The JCP Program Celebrates Fifth Anniversary, Evolution of Process and Platform

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 binaries.

A Hybrid Standards Group is Born: JCP 1.0

Onno Kluyt

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 discussion.

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

"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," Magnusson says.

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," says Magnusson.

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

Hans Bergsten

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 Magnusson.

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

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 Gingell.

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 standards" (http://www.sdtimes.com/news/079/special1.htm).

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. (http://www.fawcette.com/reports/javaone/032802/readers_choice/).