Many veteran Java developers are shying away from the Java Community Process (JCP) in large numbers and gravitating toward smaller developer communities to implement their new ideas. The JCP, once a place where developers were on a first-name basis with leadership and could e-mail a question and get an answer within minutes, has become Java the Hutt: fat, sluggish, and difficult.
Of more concern is the perception that the JCP has lost its focus. It is no longer viewed as a solutions-oriented community but as a rubber stamp to sanction specifications championed by larger corporations, who have the financial and legal muscle to lobby for specifications that will eventually mean profits for themselves.
“This is what happens to any bureaucracy that grows as fast as the JCP grew in just a short time,” said Mukund Balasubramanian, CTO of Infravio, a Redwood City, CA, Web services provider. “There are so many people and companies involved now, so many projects to follow, so much testing and research going on, that it is just getting out of hand. Just by its nature, processes like this are going to move that much more slowly. So I can understand why Java developers are frustrated with it as it now stands.”
Matt Liotta of Montara Software, an Atlanta-based maker of Web content development systems, agrees.
“Fewer and fewer new people are involving themselves directly with JCP,” Liotta said. “Instead, they are hooking up with groups like Apache and getting their wares to become de facto standards. Later, Apache pushes these implementations into the JCP under its own name.”
Has the Java API exploded?
Sue Spielman is president and senior consulting engineer of Switchback Software LLC and an author of several Java-related books. She says that there have been many Java Specification Requests (JSRs) proposed that have “exploded the Java API.”
“While this isn't necessarily a bad thing, it certainly is a challenge to the Java developer who tries to stay up on the happenings in the JCP,” Spielman said. “This could very well be one of the reasons that in the eyes of the developers, the JCP is bloated and crawling at a snail’s pace. It has become impossible for anyone to keep up on all of the JSRs that are currently in proposal and various review stages.
“One suggestion I have is that JCP restructure so that there is a tiered level to appropriate JSRs. The main tier would be one that affects the most people in the Java community. The expert groups are composed of organizations and individuals that are concerned (or interested) in the JSR. The review process takes into account the public opinions, but that doesn't necessarily mean that the public opinion will make it into the final JSR. Some credibility and respect might be regained by using a voting method of the public Java community (not just the expert group), similar to the process used in open source development. The timeframes can be limited, thereby speeding up the process, and the voting Java community will ultimately be deciding what is important for their Java development.
“At the very least, it might be worthwhile to do a test case of this with an upcoming JSR to see how the results end up. The JCP does get a lot of spec writing accomplished, so we shouldn't just toss it out the window and think the grass is greener on the other side. Community processes take time, effort, and iterations.”
Here are the four main issues that are bugging a number of Java developers right now:
Issue 1: The perception is that the JCP is just not paying enough attention to smaller players, such as individuals and start-up companies.
Walter Hurst, founder and CTO of Wakesoft, was concerned about BEA’s recent unabashed campaign to push through some of its proprietary servers to become Java standards, which could mean a major windfall in profits over time.
“Seems a little bit on the unfair side, don’t you think? What about all those smaller companies with good ideas and products? They can’t afford to be hiring lobbyists, so to speak, to get proprietary products stamped as standards.”
Issue 2: If you’re not a voting member of the JCP, the online organization is far from transparent—which ostensibly is the goal of such an open standards community.
“Many people have the impression that the JCP has become ‘slow’ because they have limited visibility into the inner workings of the community,” Balasubramanian said. “If the documentation and downloads you're waiting for are held up by months of closed debate, the process can appear very bureaucratic and slow. The JCP might benefit from a more open style, in which decision-making would still be limited to ‘participants’ but feedback and access are granted to the public at large.”
Issue 3: Many developers are concerned that political hookups between the JCP and some large corporations have discouraged a number of Java developers.
“Anytime you have consensus-driven organizations making decisions to improve relatively mature standards, you'll see enormous participation by large corporations, who have big investments to protect,” Balasubramanian said. “This is true for the JCP for Java and the W3C for the Web. These companies are big enough to employ some pretty smart people who focus their entire effort on watching and influencing what will take place within standards bodies.
“Smaller companies like Infravio aren't locked out of the JCP, but we have to focus on our core areas of expertise and contribute to the issues that are most relevant to our business. One thing that would help us do this better would be to open discussions about proposed standards from large corporations to the general public even before the formation of the JSR.”
Issue 4: An independent developer with a good idea has to get the backing of a larger organization (Apache Software Foundation, Free Software Foundation, etc.) to get a standard established.
“I think this is true to a large extent,” Balasubramanian said. “This is, again, an unfortunate side effect of a well developed and mature technology foundation such as Java. If I were an independent software developer, I would be much better equipped to go through Apache, get some popular use, and then in turn propose it through the JCP. On the other hand, this helps the community by attempting to standardize only technologies that have gained the popular vote of confidence through the open source community. This creates a veritable hierarchy of ‘standards organizations,’ where Apache is the first rung and, on clearing that, the standard reaches the JCP. Famous examples of these kinds of technologies are Struts and JSP standard tag libraries, both of which are current 'standards' with primary developers still being the Apache Software Foundation.”
The JCP’s program manager responds
Onno Kluyt, manager of the JCP program office for Sun Microsystems, was confronted with the above charges. He was candid with his response, acknowledging that politics does indeed play a major role in the JCP. However, he pointed out that individual participation, as well as corporate participation, is possible at all levels of the community.
“Individual members, [just like] corporate members, can join expert groups, propose and lead JSRs, vote in the yearly Executive Committee elections, run in these elections themselves, and serve as an Executive Committee member.
"And there are many examples of this happening. To name just a few: Doug Lea is the spec lead for JSR 166, is part of the Expert group for many JSRs, and is also a member of the SE/EE Executive Committee.
"Jason Hunter also leads a JSR as an individual (JSR 102). Steve Emerson is leading JSR 108. Conversay, a small company, is leading JSR 113 (Java Speech API). Two individuals, Brian Zimbelman and Jim Keogh, are running in this year's elections.”
It should be noted that neither Zimbelman nor Keogh made the cut in the JCP’s Nov. 18, 2002, elections. Four relatively large companies—Iona Technologies, Cisco Systems, Symbian, and Sony Ericsson—had their representatives elected, Iona and Cisco to the J2SE/J2EE Executive Committee, and Symbian and Sony Ericsson to the J2ME Executive Committee.
Kluyt was asked about the perception that larger companies are exploiting the JCP to their own advantage—for instance, that BEA used political means to get several of its proprietary servers' features sanctioned as standards by exercising its considerable industry power.
“The JCP, like any organization where competitors come together, has a certain amount of politics,” Kluyt said. “I believe that the amount of it mostly stays at acceptable and reasonable levels. The JCP does its standardization through JSRs. A JSR is led by a JCP member—for example, BEA—and has an expert group formed by JCP members, which the Spec Lead [directs]. Expert groups are typically a mix of large and small companies and individuals, and you usually find friends as well as competitors on an expert group. JSRs are approved by the Executive Committee by its voting during three milestones for each JSR: at the beginning (JSR Review), in the middle (Community Review), and at the end (Final Approval ballot). This model of checks and balances evens out any ability by the Spec Lead to have its proprietary features standardized against the will of the community.”
Jason Weiss, director of technology at Personified Technologies, said recently inJava Developer's Journal that “the [J2EE] spec is too complex. As a community, Java developers must pay attention to the beleaguered JCP and realign it with creating solutions, like those routinely released by the Apache Software Foundation.”
Java developers should take steps now to invest in the future both of Java and the community that has grown up around Java, Weiss said.
“The entire JCP must thematically reflect our desire to build solutions that simplify complex technologies for programmers. In fact, the JCP should continue to use the JSR acronym, but with new meaning: ‘Java Solution Request.’ Somewhere during this journey, the JCP has shifted from its solution-oriented roots to merely implementing specifications. This trend must be reversed...for the sake of our community.”