OpenOffice 2.0 Faces Opposition over Its Use of Java

By Steven Vaughan-Nichols  |  Posted 2005-05-09

OpenOffice 2.0 Faces Opposition over Its Use of Java 2.0 is in late beta and brings improvements in both speed and Microsoft Office compatibility to the popular open-source office suite, but some free software fans are objecting to its use of Suns Java.

OO.o ( 2.0 has been designed, according to its concept document, StarOffice/ "Q" Product Concept, to "lower cost of interoperability with Microsoft Office" and improve "its performance in … areas that are especially important to customers. The two most visible areas of improvement will be decreasing the Startup Time and Document Open/Save Time."

From informal testing by Ziff Davis Internet, the late beta of OO.o has accomplished those goals.

The problem, according to some free software voices, is that OO.o relies too much on Sun Microsystems Inc.s proprietary Java programming language in an open-source project.

While some OO.o supporters claim that the opposition is primarily the result of misinformed free-software zealots, Microsoft, or astroturfing (the use of paid shills to create the impression of a popular movement) by OO.o opponents, there does seem to be some concrete opposition to OO.o by the free software community.

Click here to read about how conflicts have come up before about the use of proprietary software in open-source projects, as even Linus Torvalds has found out.

The most visible evidence of that is that the FSF (Free Software Foundation) is "is looking for volunteers to maintain a version of OpenOffice that doesnt require a non-free Java platform."

Volunteers to lead this project are requested to contact the FSFs founder, Richard M. Stallman.

In particular, free software advocates are objecting to the use of Sun specific Java code for such OO.o 2.0 features as the new, Microsoft Access-like database management program, Base and Writers (OO.os word processor) document wizards.

While Java was used in earlier versions of OO.o, its use was much smaller and confined to more minor areas such as JDBC (Java Database Connect) driver support for Java-based databases.

The Java code in the newest OO.o, however, does not compile well with open-source Java compilers like the GCJ (GNU Compiler for Java Programming Language).

Linux vendors like Red Hat Inc. and community Linux distributors such as Ubuntu use GCJ instead of Suns programs.

Next Page: Reaching a milestone.

Reaching a Milestone

OO.o is primarily written in C++. Its open-source APIs (application programming interfaces) are licensed under the LGPL (Lesser General Public License) and SISSL (Sun Industry Standards Source License) open-source licenses. The OO.o code itself is licensed under both LGPL and SISSL.

The project has recently reached its "Milestone" build, Developer Snapshot Build 1.9.m100.

This means that OO.o is on the brink of being launched, when the FSF crystallized the objections against the use of Java into a request for volunteers to create a version that doesnt rely on Suns Java.

The FSF has also recently called on the free software community to create a free version of Java.

Click here to read about how open-source advocates have long sought to open-source Java.

Stallman explained his objections to the use of Java in such open-source projects as OO.o in an article on the "Java Trap."

"If you develop a Java program on Suns Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months. You might say, Its too much work to start over. Then your program will have fallen into the Java Trap; it will be unusable in the Free World," wrote Stallman.

Still others have suggested that instead of using an open-source Java, these components be rewritten in an entirely different language such as Ruby or Python.

However, some programmers have just gone ahead and found fixes for OO.o, which enables it to run with GCJ.

Caolán McNamara, a programmer with Red Hat who specializes in word processing, has created one such set of fixes.

A source at Sun said, "OO.o 2 works OK with GCJ" and that "Red Hat has been tremendously helpful in the effort to make that so, filing bug reports etc."

In addition, while OO.o will run without a JVM (Java Virtual Machine), it will use one if its available, and its performance has been found to be much better if Suns 5.0 JVM is used.

But, as Scott Carr, OO.os quality assurance project co-lead pointed out, "OO.o will run perfectly well without any JVM, but if there is a JVM then it has to do checks to make sure what features are supported in the JVM as well as run various functions. These are only run in the presence of a JVM."

Stephen OGrady, a software analyst at RedMonk, said, "I dont anticipate much impact on business adoption, as OO.o is simply the most credible Office alternative available at this time."

Still, "While I think Stallman et al. are likely to find some support for their efforts, said OGrady, "I believe that the nature and size of the current [OO.o] codebase will be a deterrent against credible free [software] alternatives, at least in the short term. It would be one thing if Java was limited to small features here and there, but as the platform things like Open Office Base the effort involved in porting would seem to be non-trivial."

Check out eWEEK.coms for the latest open-source news, reviews and analysis.

Rocket Fuel