Java fallout: 2.0 and the FOSS community


Author: Bruce Byfield

Several new features of the recently released 2.0 beta require a Java Runtime Environment (JRE). Since Java’s license is neither free nor open source, a small but vocal minority has responded both strongly and negatively. For instance, when NewsForge recently published a review of the beta, no other feature attracted as much comment. Some groups, including members of the major GNU/Linux distributions, most of whom repackage (OOo), have responded by looking for alternatives, often while cursing the project for the extra work it has dumped on them. How did come to rely on Java? What problems is it likely to cause? How are GNU/Linux distributions reacting to this change in a key piece of software?

It seems a decision based largely on practical considerations — and with a disregard for the consequences for both the rest of the free and open source software (FOSS) communities and the future of itself.

What has changed?

To understand the issues, it is important to know exactly what functionality depends on Java. As of version 1.1.4, the features that required a JRE were:

  • Accessibility tools, such as the Gnopernicus Screen Reader and Magnifier and the GNOME On-Screen Keyboard
  • The Report Autopilot
  • JDBC driver support for Java-based databases
  • XSLT filters
  • BeanShell, the Netbeans scripting language, and the Java UNO bridge
  • Export filters to the Aportis.doc (.pdb) format for the Palm or Pocket Word (.psw) format for the Pocket PC

While some members expressed concern about Java being used at all, most accepted the argument that these features did not affect core functionality, and were of interest to only a small minority of users. leaders are still making this argument about version 2.0. However, in version 2.0, the dependence on Java has grown. In addition to the Java-dependent features in earlier versions, 2.0 requires a JRE for:

  • Base, the new Access-like database application
  • The media player, which adds movie and sound clips to documents
  • Mail merges to e-mail, which also require Java Mail
  • All document wizards in Writer

Although some could argue that basic office functionality continues to be unaffected, anyone claiming that most users do not need Java in 2.0 may be stretching the point.

For anyone trying to run the beta without Java, the claim becomes even more strained. Even when version 2.0 is not linked to a JRE, tools that require one are still available on the menu and the only way to know which they are is to try them. When non-Java users do try them, they see an inconsistent variety of warnings. Attempt to build a new database without Java and watch the dialog window close with no explanation. Try to do a mail merge to email and learn that the task requires Java Mail from the standard window rather than a pop-up dialog. Worst of all, select Tools > Macro > Run Macro, and you’ll see a warning dialog pop up 16 times before you can continue. Aside from showing that badly needs common interface standards for features, these examples strongly suggest that 2.0 was designed with the expectation that most users would enable Java.

Why did choose Java?

For many, the observation that Sun Microsystems, the former owner of the code and the employer of many OOo’s programmers, also owns Java is all the explanation they need for’s new dependence on Java. Although conspiracy theories abound, more considered criticism suggests that is simply predisposed to accept Java solutions because of its connection with Sun. And, even though contributors make their own decisions about what programming language they use, it does seem likely that their habits from other projects would spill over into their work in the absence of a specific directive to the contrary. leaders, however, explain the decision in terms of convenience and technical merits. Most of the explanation focuses on Base, the new database application that adds an Access-like interface to HSQLDB, an existing Java database.

Daniel Carrera, community contributor representative on the Community Council, says that Base HSQLDB “is the fastest and most feature-complete database available that could be integrated given the very limited resources we have.” He adds that’s C++ core was not altered by the introduction of Base. As a result, Base can easily be replaced later.

Frank Schönheit, a Sun employee who is also the leader of the database project, goes into more detail. “This decision was not because HSQLDB is written in Java,” he says, “However, HSQLDB also didn’t get penalty points just because of being Java” during planning.

Yet, at the same time, Schönheit defends the use of Java, arguing:

  • Java allows more rapid development of components for, without struggling with the complexity of’s C++ build environment.
  • Java is mature enough to use for complex tasks.
  • To address a common prejudice, Java isn’t slow by definition, but Java makes it easy to develop poorly performing code, so developers perhaps need more self-discipline when writing Java code. However, this isn’t per se a point against Java.

These merits were apparently strong enough for the database team to ignore its own requirement that the new database be open source. Schönheit notes that programmers “are not too concerned about Java being open source or not.” Although they would prefer to use code written in C++ over that written in Java — even if the C++ code was only slightly worse — they will still use Java if it seems the better solution. “And sometimes, Schönheit adds, “this simply means that there is a Java developer who can spend time on a project, and no C++ developer who can.” In the end, Schönheit writes, the important thing is that “ 2.0 will come with its own database…. That, to us, outnumbers most, if not all, arguments we’ve heard so far against Java. In this sense, functionality is what matters.”

What are the objections to using Java?

Some might argue against Schönheit’s characterization of C++ as complex or Java as being not slow. However, technical arguments are in many ways beside the point. Objections to Java tend to be based less on technical merits than on FOSS philosophy on the one hand and the possible consequences for the future of on the other.

One of the few technical arguments against’s use of Java is that it undermines the project’s goal to be a cross-platform office suite. Many operating systems currently supported, including FreeBSD and GNU/Linux for the PowerPC, have no official version of Java. Those who wish to use OOo 2.0 on such platforms must use GNU/Linux emulation or work with an often incomplete free Java implementation. Either way, the new requirement places new pressures on the already overworked teams of volunteers working on these ports.

Other arguments against using Java focus on the possible consequences for itself. Marco Fioretti, journalist and volunteer, worries that the increased dependency on Java may destroy the project’s credibility, thereby slowing its adaptation. When asked to explain misgivings hinted at on the OOo Discuss list, Fioretti says the abrupt move toward Java undermines claims that is a mature platform. Fioretti also points out that, in jurisdictions where requirements for government use require openness, may no longer qualify. Corporate managers or lawmakers, Fioretti worries, may conclude that project members “are incompetents who produced by pure accident” and wonder, “Can I trust them?”

Just as importantly, the dependence on Java threatens’s credibility with the rest of the FOSS community. Several anonymous commentators on NewsForge’s recent review of the version 2.0 expressed doubts about continuing to use “Maybe I should stop promoting it,” one anonymous poster wrote. Several others wished that alternatives such as KOffice, AbiWord, and Gnumeric would develop faster so that they could become full replacements for

Among FOSS contributors, the reaction was much the same. The responses on the, the mailing list for those involved with integrating into the Debian distribution, are typical of ones in other pockets of the community. Anders Breindahl, for example, writes, “I find it increasingly worrying that Sun to some extent considers Java to be okay for a free office suite…. I think this makes less optimal for the Free Software community.” Similarly, in the same discussion, Sam Hiser, the former marketing lead for, characterized the change as a “challenge” that the FOSS community must answer with other software that’s more compatible with its philosophy.

Such comments suggest that little if any dialog is ocurring between those who decided to use Java and those who object to the decision. Each camp has a focus that is different from the other’s. To date, neither seems to have responded to the other side’s concerns.

How distributions are responding

The range of possible reactions can already be seen in the responses of leading GNU/Linux distributions.
For some, possibly most distributions, it is a non-issue. Slackware does not redistribute, and,
according to developer Patrick Volkerding, has no interest in doing so. As for the commercial distributions, Michael Meeks,
a Novell engineer, notes that SUSE ships with Java already. In the same vein, Mandrake CTO Frédéric
Lepied says, “Our download edition will stay free and our commercial edition is bundled with Java.”

By contrast, Red Hat and Fedora prefer to build with the GNU Compiler
for Java (GCJ)
, which is not only a compiler, but also a free JRE. This was Red Hat’s strategy with earlier versions of, and Red Hat engineers are attempting to continue it. Caolan Macnamara, a programmer at Red Hat, has
reported limited success compiling earlier developer
builds of version 2.0. However, GCJ is not yet a complete replacement for official releases of Java, and adding patches
makes the strategy painstaking and laborious at best.

Other distributions are awaiting developments with GCJ. Paul de Vrieze, a member of Gentoo’s team,
writes that Gentoo would prefer to use a free implementation of Java such as GCJ, adding that the distribution might
decide to build with Java if no other alternative existed. By contrast, Ubuntu would ship with a disabled version if a
free build was unavailable. “Ubuntu is committed to the principles of open source development,”
Matt Zimmerman, Ubuntu project head, writes, “and will not include software in our official distribution which does not meet our
licensing guidelines.”

At Debian, Chris Hall and René Engelhard, the maintainers for packages, are also working with
GCJ and following developments. According to Engelhard, they face an added difficulty because the latest version
of GCJ and the libgcc1 library are currently in only the unofficial Experimental distribution of Debian. To include 2.0 in Debian Unstable, the distribution into which new packages are initially placed, the two
maintainers might have to disable all Java-based functionality, as they did for earlier versions. Since Java does not
meet the Debian Free Software Guidelines
definition of free software, these are the only options available for including in Debian at all.


Overall, reactions seem to split along the open source and free software divide. As Richard Stallman is constantly
pointing out, although the
two communities can be grouped together for many purposes, their basic orientations
are quite different.

Open source advocates support communal development in the belief that it produces
superior software to proprietary methods. Free software supporters, however, are chiefly concerned with their
philosophical position, and are willing to undergo some inconvenience to stay true to their principles. Broadly speaking,
the defenders of’s new reliance on Java, with their emphasis on results and user convenience, can be
lumped into the open source camp. They see the decision as a practical one. In some cases, they are unconcerned
whether the decision clashes with principles.

By contrast, the resistance to the reliance on Java tends to come from supporters
of the free software position. This camp is actively looking for alternatives, both to Java and to Rather
than rely on Java, many members of the free software camp will consider shipping a disabled
version of They see the decision as irresponsible and, in extreme cases, as a betrayal.

How these differences in perspective will play out remains uncertain. Among some, they have awakened
not just the usual mistrust of Sun Microsystems,’s main contributor, but a distrust of
itself. Allowed to continue, in the long term, the lack of communication among the parties could inhibit the spread of
through lack of cooperation. In fact, given that helps to position GNU/Linux and other free operating
systems as desktop alternatives, the spread of FOSS in general could be inhibited. Another possibility is one or more
forks in the projects, although nobody is prepared yet to go that far.

Meanwhile, no one is talking to anyone else in terms that everybody can understand. The entire community is poorer for it.

Bruce Byfield is a freelance course designer and instructor and a technical journalist.