Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | OpenOffice.org should run fully on an open source Java implementation (e.g., gcj, Kaffe) | ||
---|---|---|---|
Product: | Build Tools | Reporter: | dwheeler <dwheeler> |
Component: | code | Assignee: | Martin Hollmichel <nesshof> |
Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> |
Severity: | Trivial | ||
Priority: | P4 | CC: | chris, issues, sparcmoz |
Version: | OOo 2.0 Beta | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
dwheeler
2005-03-30 00:28:57 UTC
confirming issue. set target to OOo PleaseHelp. a few remarks: I suggest to change the title from "OpenOffice.org should run fully on an open source Java implementation (e.g., gcj, Kaffee)" to "OOo should support all compatible Java implementations (e.g., gcj, Kaffee)" for obviuos reason. Also "For many architectures, Sun's JVM is simply unavailable, limiting portability." is not the point since OOo is not limited to run with Sun's JRE. Therefore we agreed in http://tools.openoffice.org/servlets/BrowseList?list=jdk&by=thread&from=351761 to - 1: the Java baseline is 1.3.1 - 2: only official Java APIs are allowed to be used - 3: Java JRE interested parties provide the support code and take care of QA, bugs etc. - 4: OOo Java implementations must be encapsulated with well specified APIs - 5: OOo Java implementations must not check against Java versions or vendors, with the only exception of workarounding bugs - 6: OOo Java implementations must not use swing, either because no free swing implemetation is available or because it makes the user interface inconsistent, this rule might be relativated in respect to 4 Java 1.3.1 is available for many platforms from different vendors, so portability should only an issue for very few platforms. I agree with you that "For many architectures, Sun's JVM is simply unavailable, limiting portability" isn't really the main point. Please ignore that sentence. But I don't think the title should be changed. I really think the title emphasizes the key issue, as captured by the various news articles about OOo. Sure, it'd be great if OOo supported "all compatible Java implementations (e.g., gcj, Kaffee)", and that's a great long-term goal. But here's why I think that should be considered a separate issue, and that the more immediate issue is support by at least one OSS/FS Java implementation: 1. Right now, I think OOo doesn't completely support ANY alternative Java implementations (though it's getting really close). Once it supports ONE OSS/FS alternative, I think it'll be easier to support MORE than one alternative, because a lot of the issues of unsupported libraries, unintended assumptions, etc. will have been worked out. So you could add your wider goal then. But it'd be easier to "walk before you run" -- make the goal ONE other OSS implementation for now, and then add the larger goal later. 2. If OOo supported 10 other proprietary Java implementations, and no open source Java implementations, the issue would still arise. If it supported one open source implementation, and no others, many people would still be happy. Yes, many would want to go beyond that, but that'd be the step at which many complaints would disappear. 3. Whether or not the implementation is completely "compatible" isn't the issue. Kaffe and gcj are known to only be partly compatible, in the sense that some libraries are not completely implemented (technically by classpath, since both use classpath). Granted, the areas that are incomplete are smaller now. But the solution isn't to ignore Kaffe or gcj; the solution in some cases may be to avoid using certain functions in OOo so that OOo will run on them (OOo already does this, with its policy to avoid Swing for that reason). Another solution may be to work with the Java implementation to add the missing function, or to implement the function inside OOo's codebase even though there's an "official" API that does it. But don't limit running OOo to "compatible" implementations; an OSS/FS implementation that's incomplete, but runs OOo, would meet this proposed bug tracker. Thanks for the reference to this useful statement: http://tools.openoffice.org/servlets/BrowseList?list=jdk&by=thread&from=351761 I hope that the recent development of Java will make this issue obsolete. Beside that: to my knowledge we currently don't have any Java components in OOo that are not running with gcj. Or am I wrong?! mba: you're partly wrong. e.g.: com/sun/star/lib/sandbox/makefile.mk: @echo This dir cannot be build with gcj because of sun.applet.AppletAudioClip of course, "sandbox" is obsolete anyway, but that's random example. which I remembered. And, most importantly: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354895 (last comment...) and yes, I hope that OOo will build with the free Java. Then this issue is not obsolete, though, since people should have choice what they use. But it might fix the pressing problems like the form wizard (will the JDK 6/7 also contain the sun.* clases?) I could never get the agenda wizard running on GNU/Linux SPARC with gcj - did anyone fix that with gcj? As Sun has released (most of) its Java implementation as open source software, this is probably resolved. Can anyone confirm, and if so, close this? I think we should keep this issue open until there is a final release available, but you're right, moreorless this issue has been addressed by GPL'd Java version. mark issue as fixed, OOo runs now with gcj, openjdk, available in the meantime with most linux distros. verified -> closed |