In The Wake Of Open-Source Java, What Dies?

One high point of the session came when Red Hat engineer Tom Tromey essentially offered to throw the project he's worked on for nearly a decade, Java compiler GCJ, onto the funeral pyre. While emphasizing that he does not speak for Red Hat, Tromey said he's arguing internally for shifting Red Hat's development resources away from GCJ and toward OpenJDK, the open-source Java SE (Standard Edition) specification Sun released this week.

"My view has always been that one good implementation is better than competing bad implementations," Tromey said.

Another project Tromey has worked on, GNU Classpath, merged code from two competing projects, and the resulting fused code base was stronger than either had been individually, he said. If Red Hat's lawyers and policy-makers sign off, Tromey would like to see OpenJDK incorporated in a future version of Red Hat's Fedora core Linux distribution.

Panelist Dalibor Topic also sees a dimming future for a project he co-maintains called Kaffe, an open-source initiative to build a Java virtual machine (VM). With Sun's own Java VM now available to developers, Kaffe becomes superfluous -- and that's fine with Topic, who has signed on as a member of OpenJDK's five-person Interim Governing Board.

"I think the future for all these projects is to find a niche where they can provide value to their community," Topic said.

Kaffe began life as a Java VM tailored for use in embedded systems; one possible future is that it will return to its roots and become a Java VM variant optimized for use in that space, Topic said.

"I'm not afraid any of these projects will die. They will expand the Java development ecosystem," he said.

What happens next depends on where Kaffe developers push the project. In open-source, community-driven development, participants lead with their code. If they still see value in the old projects, they'll continue contributing and steer them in new directions. If they don't, the tributaries will dry up as developers reroute their efforts to the OpenJDK stream.

As Tromey put it: "In the free-software world, nothing ever dies. It just becomes sort of zombified." Still, like Topic, he thinks projects like GCJ and GNU Classpath will survive as niche initiatives.

One panelist took a markedly different view, arguing that the Java community needs rivals to Sun's official implementation. Geir Magnusson, Jr., chair of the Apache Software Foundation's Harmony project, said Harmony still draws participants and plans to stick around.

"I think the Java ecosystem has always thrived because of its diversity," Magnusson said. "The fact that we had diversity for some number of years has helped bring everyone forward in terms of performance, stability and operational features."

Founded in 2005, before Sun's decision to open-source Java, Harmony's goal is a full, certified implementation of Java SE. Originally, Harmony was created to fulfill community desire for open-source Java; now that Sun's official Java implementation fills that need, Harmony is left with one main point of differentiation: its license. Harmony carries the Apache License, a less restrictive, more commercial-development-friendly license than the GNU General Public License (GPL) Sun selected for Java.

"I realize that's a really narrow point, and that 99.999 percent of Java developers just don't care," Magnusson conceded. Nonetheless, he wants Harmony to go forward as an OpenJDK competitor -- the project has even been scrapping with Sun lately about licensing terms for the technology compatibility kit (TCK) it needs to certify its Java SE compatibility. (Sun executives, including chief open source officer Simon Phipps, said this week that Sun has no update on the status of its talks with Apache about Harmony's TCK license, and that the two sides remain in negotiations.)

Like stakeholders in existing open-source Java projects, solution providers and ISVs that deal with Java development face decisions about how to move forward in the wake of Sun's Java release. One attendee at Thursday's panel discussion, Ephox product manager Adrian Sutton, said his company is "doing a bit of soul searching" about how much of its own development work to contribute back to OpenJDK. An Australian developer of Swing-based HTML editing tools, Ephox has squashed a number of bugs in the Swing GUI toolkit's text-editing capabilities. Now, the company is trying to decide if that bug-fixing work is a competitive advantage, or if it's more worthwhile to contribute it back to Sun to strengthen Swing.

"There's probably an incentive. We need to figure out what it is, to make us invest the time in submitting and going through the review process," Sutton said.

The more developers give back to the OpenJDK code base, the stronger the Java ecosystem as a whole will be, several panelists argued. As GNU Classpath maintainer Mark Wielaard quipped, to sum up the open-source ideals behind panelists' projects' diverse Java variations: "What we all want is the freedom to be different, but not to actually be different."