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:"

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.

Figure 1. The Java Community Process. Click on thumbnail to view full-size image.

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

1 2 3 Page 1
Page 1 of 3