Toward a free Java

Every year around JavaOne there is a lot talk about Java and whether we will ever see a free alternative for it. Since 2000, various projects aiming to provide a free alternative for the Java platform have been working together toward this goal. This cooperation became much stronger when in 2003 various developers from GNU Classpath, Kaffe, GCJ, JamVM, IKVM/Mono and others met each other in person during some informal meetings at Linux Kongress, FOSDEM and LinuxTag in Europe. What had before been competing projects became projects that would cooperate wherever technically possible, especially around the core class libraries as provided by GNU Classpath. The competition turned into something positive and playful. The GNU project even sponsored the Fast Free Eclipse contest which was ultimately won by GCJ in August 2003 (with JikesRVM and IKVM/Mono close behind).

At the end of 2004 Red Hat brought all these groups together again during the Alternative Runtime Summit at the MIT campus in Boston. They invited a large and diverse group of people to talk about their projects and also invited representatives of the traditional Gnome, GCC/GDB/GNU toolchain and Mono groups, plus representatives of the Apache and Eclipse groups, to discuss various ways to build bridges between the various communities. Richard Stallman gave a lecture on the Java trap and a Sun representative was also invited. Sun decided to not join the fun at that time, but we did establish that our goals were not that different.

Although none of us knew how the future would look, it was clear that everybody was very positive about sharing their experiences and working ever more together. Everybody left the Alternative Runtime Summit feeling our goals united us much more than the different technical paths we were taking to reach them divided us. There was also a definite feeling that we would be able to provide a full free alternative to the Java platform. And that the alternative(s) would be much more then Java and that it would go beyond and extend the traditional GNU platform.

The realization that we were in this together and that a free alternative for Java should be integrated as much as possible with the rest of the free platform had some important results. Our next meeting at FOSDEM 2005 was all about building bridges. We focused on alternative execution mechanisms like GCJ and Mono, hooking into Gnome with java-gnome and doing continuous integration tests against the Apache Java code base through Gump.

Another way to cooperate and, at the same time, help our users to try out our work more easily was done by collaborating with the various GNU/Linux distributions to package traditional Java programs and libraries so they could be easily used with the various free alternatives. During the Oldenburg DevJam Meeting various packagers, compiler and runtime hackers came together to define standards for interoperability and packaging conventions. Users can now easily try out various compilers, libraries and the alternative execution strategies for their code. This effort was so successful that even Sun is now adopting the JPackage alternative ideas for their own (proprietary) packages aimed at the GNU/Linux platform (although their current license seems to disallow any mixing and matching with the various free subcomponents).

One of our success stories is the packaging of Eclipse for the various GNU/Linux distributions. Although Eclipse traditionally emphasizes the proprietary Windows platform, the Eclipse developers have been extremely supportive of our efforts and have helped find alternatives whenever the free toolchain didn't have a particular language or library feature yet.

After setting up Gump integration tests with Kaffe and seeing that we were almost there, the Apache group became very enthusiastic about joining in. Since a lot of the packages that are bundled by the free distributions were actually based on code by the Apache group, that seemed like a very cool idea. After a couple of conference calls between the FSF, ASF and various project members we launched the Harmony! project.

Unfortunately, from the start the project seemed plagued by miscommunication and confusion about intentions. The original announcement hadn't been proofread by some of the participants which lead to corrections by the Kaffe team, clarifications by the GCJ team and updates from the GNU Classpath team about the original intent of the project. Sadly, these first impressions were hard to shake off.

And soon a lot more miscommunication and confusion started. Some people joined that were very vocal about the project being Apache (and not GNU!), some people said that their company regulations didn't allow them to study anything on gnu.org, including the GNU Classpath VM Integration Guide. Others said that using anything that used the "gnu." Java package namespace would be impossible to clear with their legal departments. IBM wanted to donate code, but suggested using an alternative runtime interface which would be suitable for their proprietary J9 VM (but not for any of the 30 projects currently based on GNU Classpath).

After 9 months of trying to cooperate we organized a new meeting during FOSDEM 2006 to get all players together again. And, although 60 people attended, including core GNU Classpath, GCJ, Kaffe, Cacao, JamVM and IKVM hackers, only one Harmony person showed up, and none of the people from the backing companies. All this means that, despite the fact that there is now some code available donated by Intel, there is no practical cooperation between the original free software projects backing Harmony and the project now known as Apache Harmony. All this made some people think of Harmony as a company consortium in the guise of an ASF project and not a full community project. But there is still some hope that the final result will be merged with the existing projects at some point and that there will be more community involvement in the future.

One thing we had completely overlooked in our Harmony effort was the fear uncertainty and doubt in the Apache Java world about the GPL, the LGPL, and the GPL exception statements used by GNU Classpath and other GCC runtime libraries. At the Alternative Runtime Summit we had discussed The Free Software Community, the GPL, Compromising and Control. And David Turner from the FSF was present to explain LGPL and Java. We (the Classpath developers) had naively assumed that in turn for using an explicit GPL + linking exception for GNU Classpath, so it could be used with code distributed under the ASL, we would get back an exception to the ASL for larger works distributed under the GPL.

Sadly that did not happen. Partly because the Apache group doesn't hold the copyright on code contributions so cannot change any of the terms of the code it distributes (the FSF had offered to track down all contributors, but this proved to be too large a number to be practical) and partly because it doesn't want to make any exception for its code base since it fears that would confuse its users. But most Apache people did agree that it would be nice if code distributed under the ASL would be reusable in larger GPLed works, just like it is reusable for proprietary code. And the FSF agreed that none of the extra requirements in the ASL were inhibiting the freedom of users.

As a result, you will see various improvements in the GPLv3 draft based on our discussions. The GPLv3 clarifies the system library exception, explicitly states people can grant exceptions to the GPL, like the FSF has done for the various GCC runtime libraries, and adds compatibility clauses for certain requirements found in the ASL and EPL licenses. We hope that when GPLv3 is finalized we will see more code flow between the projects and reuse of various Apache and Eclipse technologies in the GNU, Gnome and KDE worlds.

One of the efforts that does seem to pay off is our cooperation on the Mauve Completeness, Correctness and Compatibility testsuite. Mauve contains more than 45.000 core library tests and has various modules for testing core class library implementations, byte code verifiers, source to byte code and native code compiler tests. It also contains the Wonka visual test suite and the Jacks Compiler Killer Suite. Every release of GNU Classpath comes with a little overview of how well we do on the tests. This is especially important because we have so many different compiler and execution mechanisms available. It also enables us to measure compatibility despite the fact that we don't have access to the TCK suite that Sun uses to determine whether something is Java compatible.

Now that Sun is again thinking about whether and how to open up more we have even been in contact with some Sun engineers who would like to start some cooperation by combining out testsuites. For Sun compatibility has always been a very touchy point. So some hope this will be the start of a better cooperation of the Sun Java group with the rest of the free software community. It seems that our continuous progress and nice integration with the GNU/Linux desktop at least got their attention.