Effort on the edge, Part 1
Does the JCP adequately balance innovation with maintenance of Java’s standards?
Consider the familiar pattern: As a technology matures and as organizations increasingly invest in that technology, the need to preserve its common standards and practices also increases. The status quo sets in, as that technology’s major stakeholders grow progressively more unwelcoming to innovative ideas. As innovation finds other outlets, the technology grows less relevant and, with time, goes the way of the dinosaurs.
Has Java reached that stage already? Or is Java just now starting to really take off? Those are fair questions considering Java has enjoyed seven years of growth as a programming language and environment. Java has about three million active developers, has gained acceptance as a staple of the enterprise computing landscape, and has become the lingua franca of university computer science curricula. With all this success, has Java reached its zenith? Or will the language’s success evolve into a nonlinear explosion of further adoption and ubiquitous use?
These questions prove especially timely as Sun begins to loosen its reins on Java. It used to be that Java meant Sun Microsystems—that all progress in Java depended on Sun’s support and endorsement. Those who still believe that see a cloudy future for Java, with Sun’s sagging revenue growth and, hence, impaired ability to financially back the technology. In a recent interview with CBROnline, Java inventor and Sun Fellow James Gosling admitted this much: “It’s hard to criticize [the C sharp language] because it is such an obvious [Java] clone. The real threat from Microsoft is [that] they can out fund us. They fund developers…Sun is not in a position where we can buy partners” (from “Gosling: Microsoft’s Java Threat is Financial, Not Technical,” Gavin Clarke (October 4, 2002)).
Whatever Sun’s future holds, the company no longer wields sole sway over Java’s direction. Over the past four years, the company has quietly shepherded Java’s growth and has vested increasing control over the language’s future with Java community members through the Java Community Process, or JCP.
The JCP’s key role is to define and maintain the specifications that define Java. You become a JCP member when you sign the Java Specification Participation Agreement, or JSPA, thereby agreeing to follow the JCP’s rules and regulations. Rob Gingell, Sun’s chief engineer and fellow, who chairs the JCP, notes that presently 58 percent of Java specification requests, or JSRs, are led by Java community members that are not Sun employees. If that trend continues, Sun will have less and less say over Java. Simultaneously, Java’s future will depend more on the JCP’s effectiveness.
Since constant innovation is the only known antidote to going the way of the dinosaurs, how effective is the JCP when it comes to innovation? Or, is the JCP friendly to new ideas that raise Java to the next level? Does it frown upon truly original, radical thought and favor instead small, incremental change to what already exists in Java? And, most important: Why would an innovator need a community process?
Read the whole series “Effort on the Edge:”
- Part 1: Does the JCP adequately balance innovation with maintenance of Java’s standardshttps://www.infoworld.com/?
- Part 2: A fact-based analysis of the JCP’s effectiveness
It’s all (about) toast
To see the rationale for a community process, put yourself in the shoes of someone wanting to introduce innovation into Java. Or, better yet, imagine yourself in that person’s bathrobe.
One autumn morning, as the scent of freshly brewed java awakens you, you head for the kitchen and toss two thin slices of sourdough into the toaster. In a few short minutes, instead of the familiar smell of toasted bread, a thin layer of smoke billows over the room. You sigh in frustration as you realize your roommate adjusted the toaster to its ultimate power!
Then comes an idea: If the toaster were controlled by software that knew your preferences, you could now be spreading Grandma’s marmalade onto two perfect pieces of toast instead of tossing their carcasses in the garbage. And if toaster ovens came with embedded JVMs, you could design an API for toasters in Java! With that thought, you rush to sketch a preliminary design for your new idea—an API for Java-enabled toasters.
Necessity and curiosity not only are the architects of innovation, but, according to open source guru Eric Raymond, also are the originators of many a successful software project: “Every good work of software starts by scratching a developer’s personal itch,” he says. If that burned toast made you itch or perhaps wrinkled your nose enough to start thinking about a solution to the problem, then you’re on your way to becoming the solution’s originator—an innovator.
But wait…don’t large corporations and universities lead real innovation? After all, an individual developer with a whiteboard design seems a long way from millions of toaster ovens warming bread with the same API. How can an individual with an idea about a Java technology see his vision become reality?
The answer to that question will shed some light on Java’s future. Since all modern programming languages and environments define Turing-complete systems, you can choose any of them to implement your ideas—C#, Visual Basic, Python, C++, Perl, Delphi, COBOL (Common Business Oriented Language), and so forth. Some are more conducive to certain tasks than others; some are also more conducive to innovation than others. In seeing your innovation become reality, you want to implement it using a technology that’s most friendly to new ideas in general, one that provides the least roadblocks and ensures your idea’s broadest dissemination.
A dangerous waterhole
Back to your idea, you develop a preliminary sketch on a whiteboard, or on the back of a napkin or envelope, for an API to control toasters programmatically. Regardless of how you come up with your first design, you quickly realize that your initial sketch might not represent the best possible blueprint for a toaster API. After all, you’re a software developer, not a toaster expert. So, as soon as you get to your office, you look up leading toaster experts on the Web and fire off some emails: Would they be interested in participating in the toaster API’s design? Do they even think such an API is a good idea?
Soon enough, some of those experts reply: “Yes, it’s a great idea, the best one since the invention of sliced bread.” They agree to work with you and provide input into your design. Thus, your original idea leads to a process that defines a feasible technical solution. That process’s result would be a set of guidelines or specifications. You also need to decide who can use those specifications, and how: in other words, you need to develop your licensing policy.
At that point, you encounter your first dilemma: Your toaster experts all work for competing companies. How can they cooperate on a common API, when they represent cutthroat competitors in the marketplace?
Two leading experts on open source communities, Richard Gabriel and Ron Goldman, produced “The Jini Community Pattern Language” in 1998, when the Jini community was in its infancy. They aimed to isolate the factors needed to create a new community and marketplace for innovative software ideas. They borrowed the notion of reusable, object-oriented design patterns to describe how a community interested in a common solution might work, even when competing companies are members of that community.
The Dangerous Waterhole pattern illustrates why competitors might want to cooperate in a process to develop a new technology or standard. Imagine a watering hole in a jungle. Animals eye the hole from a distance, but not one goes forward, lest it fall prey to another beast lurking behind the trees. But once an animal large enough or otherwise immune from sneak attacks descends on the watering whole, other animals soon follow suit.
A similar pattern might draw the world’s biggest toaster manufacturers to the same watering hole. However, they’re unlikely to initiate a common API standard on their own; why would competitors follow one company’s proposal? Thus, little progress is made, until you, a neutral third party, come along and invite those companies to work together. A competitor refusing to join risks having its interests ignored.
The iterative JCP process
At its best, the JCP is such a waterhole for those interested in advancing Java. It provides a forum for proposing and discussing changes to Java, and offers a clear blueprint for how those changes take effect. In a nutshell, that process is quite simple:
Any JCP member can propose a new specification by completing a form, the JSR. The JCP executive boards then either approve the JSR for further development or reject it. The JCP has two such boards: one oversees those JSRs that affect J2SE (Java 2 Platform, Standard Edition) and J2EE (Java 2 Platform, Enterprise Edition), and the other directs work on J2ME (Java 2 Platform, Micro Edition)-related JSRs. Each executive committee (EC) consists of 16 members, some of which are elected by the popular vote of all JCP members, while others are nominated by major Java licensees and ratified by public vote. In addition, Sun is a member of both ECs, and has special privileges and input into JSRs that propose to change the J2SE/EE/ME platforms themselves (umbrella JRSs).
Suppose you proposed a JSR, “Java API for toasters,” which likely relates to J2ME. After the J2ME EC approves it for further development, you form your expert group and together develop a draft proposal. You, or another expert group member, acts as the specification lead. Once you complete a first draft, you make it available for review by all JCP members. During that stage, which may last from 30 to 90 days, any JCP member can read and comment on your specification. If you didn’t specify how to toast bagels, another community member might point out that gasping lack.
After that stage closes, the EC reviews the community draft. If the committee decides the draft is solid, you would then prepare the draft for general public review, where anyone with an Internet connection, even non-JCP members, can review and comment on your draft. During that feedback period, you’d also complete the specification’s reference implementation to prove that the technology is feasible. In addition, the JCP requires you to create a set of tests—a technology compatibility kit (TCK)—to verify the correctness of the spec’s future implementations.
After the 30- to 90-day public review period, the EC again votes to either approve or reject the final draft. If the EC approves it, the JSR becomes an official Java standard. The JSR is maintained throughout its lifetime by the spec lead (you) or by someone you designate. Figure 1 illustrates the process by which a JSR is approved.
At the time of this writing, the JCP has approximately 650 members. According to Onno Kluyt, director of Sun’s JCP Program Office, about 30 percent of the members are large, international companies, while about 20 percent are individual members not representing any company. The Java community represents a fairly international crowd: about 42 percent of members live outside the US, says Kluyt. As we write this, the number of JSRs totals 191, with 59 Java community members serving as project leads.
Take your project open source
In designing your Java toaster oven API, you might decide that going through the JCP is more trouble than it’s worth. Instead, you might set up a project on SourceForge.net, communicate with your experts via email, and develop the specification as a work-in-progress document on your Website.
“Either path is feasible,” notes Sun’s Gingell. “Choosing one involves navigating among several considerations: requirements regarding namespace usage, efficacy of managing the effort to create the API and ongoing support, and relationships with relevant communities.”
Gingell also observes that “the JCP owns the java.* and javax.* namespaces, and changes in those namespaces are managed exclusively through the JCP.” If you decide to use org.toaster instead, then you don’t have to use the JCP. However, adds, Gingell, “you might still choose to use the process, either formally or informally. An informal usage might mean that your SourceForge-based project takes the JCP operating procedures and rules, and runs the effort along those lines. Of course that would not be a requirement, but perhaps something people just choose to do for efficiency or convenience.”
In addition to its namespaces and well-defined process, the JCP also offers an infrastructure. “A more formal usage might bring the activity into the JCP, still as part of the org.toaster namespace, but using the JCP’s infrastructure to facilitate the work in some way that you find convenient, as opposed to setting it up for yourself,” says Gingell. “Perhaps you’d want to take advantage of the JCP’s developer community and interested parties in some way, or to ensure harmony with other [Java APIs], or to use any perceived influence and credibility the JCP might provide for your effort.”
But perhaps your biggest reason for going through the JCP with your Java toaster API is because that route allows you to call it the official Java Toaster API. “All projects that hope to become part of the standard Java specification go through the JCP,” says Sun’s leading open source advocate Danese Cooper, who manages Sun’s Open Source Programs Office. “If you did your project at [SourceForge] you might indeed succeed in creating a de facto standard, but until someone proposed to support that standard in a JSR through the JCP, it would not be part of Java. You’ll notice this happened with SOAP [Simple Object Access Protocol] and UDDI [Universal Description, Discovery, and Integration], for instance.”
Should Java be open source?
Those of us who witnessed—and perhaps even participated in—the growth of Linux from a few downloadable floppy images to an operating system running mission-critical enterprise applications often wonder: why bother with all that process? If Sun wants Java to grow and counter any competitive threat to who-knows-which competitor, why isn’t it making the technology open source so that Java can develop the way Linux did? Linux doesn’t have a formal community process, yet it has done exceedingly well.
The basic idea behind open source is simple: By making the source code for a piece of software available to all, any programmer can modify it to better suit his or her needs and redistribute the improved version to other users. By working together, a community of users and developers can improve the software’s functionality and quality, and thus directly contribute to innovation. While Sun does make available the source code to the JDK and other Java technologies, the license that governs that source code restricts distributing modified versions of that code. Those provisions separate Java from truly open source initiatives, such as Linux or the Apache Web server.
As open source advocate Eric Raymond astutely observes in his essay, “The Magic Cauldron,” the open source community also has a relatively well-defined process of checks and balances, and that process is partly the reason for the high quality and availability of open source software. Why wouldn’t that process serve Java equally well?
Many in the Java community believe that it would. IBM, the company that some estimate has devoted more resources to Java than any other corporation, including Sun, shares that view. In an interview with ZDNet (“IBM Pressures Sun to Free Java,” David Berlind (September 2002)), IBM’s director of e-business strategy, Bob Sutor, pointed out the company’s desire for an open process and licensing model: “IBM absolutely loves Java. We think we’ve done more work than anybody else on the planet in terms of Java’s reliability and performance to make it enterprise ready. Moving forward, we want to be constructive. We just think the whole way that Java is standardized can be done better.” More recently, as a member of the expert group for JSR 121, “Application Isolation API Specification,” on October 21, 2002, the company qualified its approval vote of that specification with the following comment: “IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is…a statement of IBM’s preferred licensing model.”
Java is already a leading programming language for open source projects. A quick look at Freshmeat.net reveals that about 11 percent of its registered open source projects use Java as their primary programming language. Java is also now the leading language used in university computer science research projects that often release their results under an open source license. And several open source Java projects have become de facto standards, even though they lack JSR status; Apache Ant and JUnit are just two examples.
Binary matters
Of course, when all is said and done, whether your API is an officially blessed Java standard might not matter much. SOAP and UDDI represent good examples of technologies that had nothing to do with any community process at first and became widely used because either users or a few large firms started to use them. As with SOAP or UDDI, what does make a difference for your innovation is how widely and universally it is employed. In ensuring that all Java innovations, whether JSRs or open source projects, enjoy the broadest possible distribution, the JCP, paradoxically, plays a most important role.
The reason for that lies more in that little gray box you call your computer than in some fancy philosophical argument. As Bill Venners, author of Inside the Java Virtual Machine (McGraw-Hill Osborne Media, 2000) reminds us, Java is really four distinct things: a virtual machine blueprint, a binary (byte code) format specification, a programming language, and a set of class libraries defined in that programming language. While programmers think mostly of APIs and class libraries, when your code hits the silicon, it’s all binary. You might have open source libraries at which you can hack away at will, but you certainly cannot play with the instruction set of the chip that runs your compiled software.
The problem of dispensing with the JCP is that without its TCK requirements, anyone can play around with the instruction set embedded in the JVM and still distribute that altered code as a JVM. It’s akin to a situation where all those little gray boxes peppering offices and homes tick to a different Pentium specimen that may or may not be compatible with other varieties of the same chip. Then, when you install your next Red Hat Software distribution, the binaries fail in unpredictable ways because of slight CPU incompatibilities.
“The open source community likes to believe that the systems will not be taken in incompatible directions,” says Ken Arnold, chief architect at EventMonitor and coauthor, with James Gosling and David Holmes, of The Java Programming Language (Addison-Wesley Publishing Company, 2000). “When Write Once, Run Anywhere is your reason for existing, this is not something to be taken lightly. If you make an incompatible version of sendmail, the person you mostly end up hurting is yourself. If you make an incompatible version of Java, then the people who get hurt are those who try to ship code or run shipped code. Dividing the Java universe into two incompatible versions does more harm to Java than an incompatible sendmail does to mail systems.”
Adds Sun’s Rob Gingell: “Product fragmentation in the marketplace relates to the existence of binary standards. The Linux community effectively exists on IA32 [the Intel 32-bit instruction set architecture] and lives synergistically with an emphatic standard of the PC hardware marketplace. That, coupled with the preexisting Unix applications base, has been a strong enough market force to prevent fragmentation.” He should know, as he was instrumental in developing the Solaris Application Binary Interface, as well as the format of .so (shared object) files—the equivalent of DLLs (dynamic link libraries) on Unix—in your library directories.
“The industry is full of pundits who predict Linux’s inevitable fragmentation, but I don’t agree that fragmentation is inevitable,” he continues. “What will prevent it are the binaries…that are interchangeable among the distributions, which are also binary products. It’s that attribute, and not the terms under which the source is available, that prevents or causes fragmentation.”
Arnold also notes that “one thing open source projects have almost never had to deal with is someone actively hostile and who doesn’t care to control something if they can just fragment it enough to destroy it. Look at Microsoft’s first play at mucking with Java. The keywords they added weren’t blindingly powerful, but were interesting enough to some people to say ‘sure.’ But if there are two versions of Java, then Java’s just another language, not a deployment platform you can rely upon. And Microsoft surely would have been nearly as happy to fragment the Java world as to take it over. Either way, it ceases to be a threat to them. I can’t think of an open source project that had to deal with that kind of assault.”
Leaders in the open source community admit to that much. Sun’s Danese Cooper points out the dilemma between optional and mandatory compatibility requirements: “I’ve asked many open source experts to come to Sun to talk about the merits of open source, and when we talk about Java, the question of compatibility always comes up. It’s clear that mandatory compatibility and open source can’t coexist. Optional compatibility (and optional branding) are consistent with open source. So the question is, ‘Can the value proposition of Java withstand optional compatibility?’
“Personally,” she adds, “I’ve seen the power of community censure that stopped embrace-and-extend from overtaking the Internet protocols at Apache, for instance. But I’m an optimist. The stewards of Java have so far not felt comfortable taking the final open source step…although Sun has said that a time in the future [will arrive] when the market will protect the value proposition of Java sufficiently and the license model won’t matter.”
Better than open source?
With the JCP 2.5, Sun may have started down that final step. With 2.5, the only thing differentiating the JCP from pure open source projects is the JCP’s requirement that projects produce and maintain a compatibility suite, along with the specifications and a reference implementation. The latest JCP changes specifically let a JSR spec lead choose any working style she wishes during the JSR’s development process. What’s more, those latest changes also enable a JSR lead to determine the licensing model under which the expert group releases the specifications, the reference implementation, and compatibility test kit. Thus, if you so choose, you can now run an open source project through the JCP—you can use an open source license for your project.
Another important area the JCP 2.5 clarifies is the assignment of intellectual property used during an expert group’s work. The toaster experts working on the Java Toaster API expert group will likely be employed by companies that have invested decades of research into the intricacies of browning the perfect toast. Naturally, they will be interested in protecting the value of the work they have invested so much into.
One way they can do that is by filing and protecting patents on their innovations. According to Larry Rosen, of the law firm Rosenlaw.com, Sun has many patents on Java-related technologies and has not made clear to Java users just what patents apply to what parts of Java. “The open source community has asked Sun a number of times to disclose their patents concerning Java. However, Sun has so far not done so,” says Rosen, who also acts as legal counsel to the Open Source Initiative, opensource.org.
“By not knowing what patents are outstanding on a given technology, users of that technology can, unintentionally, infringe upon those patents,” he continues. “That is not limited to Sun and Java, however. The open source community has up to now acted as ostriches with regards to patents. That attitude has prevented many large corporations from using and contributing to open source software.”
Rosen recently spearheaded an initiative to address the need for patent disclosure in open source projects. He and his colleagues at the Open Source Initiative developed a new Open Source License that explicitly calls for patents to be identified and patent rights to be assigned. When you use a piece of software released under the Open Source License, that software’s creator “grants you a worldwide, royalty-free, nonexclusive, perpetual, non-sublicenseable license, under patent claims owned or controlled by the Licensor.” If you decide to release your toaster API for Java under the Open Source License, you grant your users the right “to make, use, sell, and offer for sale derivative works” royalty-free.
But how can you, as a JSR lead, grant that right, where those patents are owned by the companies that make up your expert group? The JCP 2.5 JSPA addresses both in-bound and out-bound intellectual property. In-bound intellectual property is the set of patents, licenses, or other rights that you and your expert group members bring to the table. Out-bound intellectual property signifies the rights of your specification’s users, reference implementation, and compatibility test kit.
In essence, when your experts join your expert group, they grant the spec lead the right to sublicense the existing intellectual property they bring to developing the JSR. That not only includes patents, but copyrights, trademarks, and trade secrets as well. You and your experts can, in turn, choose whatever license form you desire for your output. If you choose the new Open Source License, you steer your technology’s users clear of possible infringement on patents, trademarks, or other intellectual property they might not initially be aware of.
Sun is playing by those new rules. “Prior to the use of JCP 2.0, [Sun’s Java licensees] were the only ones to gain access to the technologies needed to implement the things that comprise the Java technology from Sun,” explains Gingell. “And licensees typically got all of the specifications, implementations, and conformance tests along with service and support programs as a bundle.
“One way to look at JCP and its evolution is that it’s a process of unbundling all of these things. As of JCP 2.5…the specifications, reference implementations, conformance tests are all separately available,” adds Gingle. “J2SE is not today available under the terms of JCP 2.5. Sun did commit to making available some of the JSRs it has led under 2.5 terms prior to the adoption of 2.5 by the JCP, and we have committed that all prior JSRs would be available under those terms but on an indefinite schedule. The expectation is that those changes will occur as maintenance on the technology occurs, roughly over the course of a year or so we’d expect.”
To facilitate open source J2SE implementations, in August 2002, Sun announced a scholarship program for qualified nonprofit organizations that require access to Sun’s compatibility tests to verify their adherence to JSR standards. Nonprofit groups that qualify can obtain Sun’s compatibility test kits free of charge.
Gingell notes that, “When J2SE is available under the terms of JCP 2.5, if someone wanted to implement it from specifications, they could do so without also licensing the reference implementation. They would have to license the TCKs to verify that they’d made a compatible implementation. They would thus have to be a TCK licensee, which would be available for free to qualified nonprofits.”
Innovation or stagnation?
While the last JCP changes address most issues the open source community raised about Sun’s treatment of Java, we must still ask how inclusive the JCP is in representing the 3 million-strong Java developer community.
Participation in the JCP generally requires the payment of an annual fee. To defray costs, Sun’s JCP Program Office charges an annual fee of 00 for individuals not representing any company, and ,000 for company members. If you are only interested in participating in a single expert group, as an individual, you don’t have to join the JCP; hence, you pay nothing.
In addition to that annual fee, running a JSR can be time consuming. In Part 2 of this article, several JSR leads will share their experiences and recount the true effort involved in creating a successful JSR. Given the required time and financial commitment, a danger is that large corporations start to dominate the JCP’s agenda. Large companies with many existing customers often prefer incremental advances in step with customer requests. Consequently, breakthrough ideas that may infuse Java with vitality and allow it to remain relevant over time might be increasingly difficult to propose through the JCP. “The JCP,” according to Gingell, “is about trying to find a vehicle that both rapidly meets the customer interests in universality while recognizing that innovation occurs primarily as an effort on the edge.”
Is the JCP currently accomplishing this goal? We will answer that question in Part 2, as we analyze the JCP’s effectiveness from publicly available data.
