Author: Bruce Byfield
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 OpenOffice.org 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 OpenOffice.org 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.
OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org choose Java?
For many, the observation that Sun Microsystems, the former owner of the OpenOffice.org code and the employer of many OOo’s programmers, also owns Java is all the explanation they need for OpenOffice.org’s new dependence on Java. Although conspiracy theories abound, more considered criticism suggests that OpenOffice.org 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 OpenOffice.org work in the absence of a specific directive to the contrary.
OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org’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 OpenOffice.org, without struggling with the complexity of OpenOffice.org’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 OpenOffice.org 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 “OpenOffice.org 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 OpenOffice.org on the other.
One of the few technical arguments against OpenOffice.org’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 OpenOffice.org volunteers working on these ports.
Other arguments against using Java focus on the possible consequences for OpenOffice.org itself. Marco Fioretti, journalist and OpenOffice.org 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 OpenOffice.org is a mature platform. Fioretti also points out that, in jurisdictions where requirements for government use require openness, OpenOffice.org may no longer qualify. Corporate managers or lawmakers, Fioretti worries, may conclude that project members “are incompetents who produced OpenOffice.org by pure accident” and wonder, “Can I trust them?”
Just as importantly, the dependence on Java threatens OpenOffice.org’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 OpenOffice.org. “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 OpenOffice.org.
Among FOSS contributors, the reaction was much the same. The responses on the debian-openoffice.org, the mailing list for those involved with integrating OpenOffice.org 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 OpenOffice.org less optimal for the Free Software community.” Similarly, in the same discussion, Sam Hiser, the former marketing lead for OpenOffice.org, 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 OpenOffice.org, 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 OpenOffice.org 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
OpenOffice.org, 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 OpenOffice.org 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 OpenOffice.org 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
OpenOffice.org 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 OpenOffice.org in Debian at all.
Conclusion
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 OpenOffice.org’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 OpenOffice.org. Rather
than rely on Java, many members of the free software camp will consider shipping a disabled
version of OpenOffice.org. 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, OpenOffice.org’s main contributor, but a distrust of OpenOffice.org
itself. Allowed to continue, in the long term, the lack of communication among the parties could inhibit the spread of OpenOffice.org
through lack of cooperation. In fact, given that OpenOffice.org 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.
