Red Hat Bugzilla – Bug 171692
OOo-2.0 won't allow selection of other (e.g. Sun) Java JREs
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Epiphany/1.6.5 Description of problem: The version of openoffice.org-2.0.0 currently in "update-testing" does not allow the user to select an additional java JRE (in addition to gcj which is automatically installed as a dependency). Version-Release number of selected component (if applicable): openoffice.org-2.0.0-3.x How reproducible: Always Steps to Reproduce: 1. Select Tools->Options->Java from menus and click "Add" to add a new JRE 2. File-chooser dialog opens 3. Attempt to select a directory containing a JRE (e.g. Sun Java v-1.4.2 or 1.5.0) Actual Results: OOo reports (incorrectly) that the selected directory does not contain a valid java runtime environment. I've tested with both Sun-java-1.4.2 and 1.5.0 and it fails in both cases. Expected Results: The select JRE should have been registered. This process works fine for the OOo-2.0 version downloaded directly from OpenOffice.org. Only the fedora core rpms are broken in this respect. Additional info: Without external JRE support, a certain amount of OOo functionality is disabled, since a number of features don't work with gcj yet.
Correct. You can only select gcj because of numerous reports of people selecting other JRE's which then didn't work with OOo. What doesn't work with gcj ?
The most recent issue I had with gcj was xhtml export didn't work. Also, JMF (for the media player) doesn't work with gcj. As it happens, both these examples are broken in other respects (JMF-support is totally borked since somewhere around the 1.9.90 builds, and xhtml export missed things like XForms etc.). My experience was that the Sun JREs worked fine with the previous FC4 OOo betas. I think removing the facility to specify other JREs is a little dracionian. The ability to swap JREs is useful to help understand if a problem is specific to gcj (or another JRE) or a problem with OOo itself. Also, who's to say some users may not have OOo java extensions which only work with a specific JRE (not the Java Ideal, I know but it happens); OOo shouldn't place unecessary obstacles in the users path. If you really feel disabling support for other JREs is essential, I think a sane error message explaining as such is required (if only to avoid multiple bug-reports like mine).
I have same view on this topic. So if you will not support other java than gcj is there a way to workaround this limitation.
Created attachment 120597 [details] javavendors.xml copy this to /usr/lib/openoffice.org2.0/share/config/javavendors.xml and the sun jre is selectable. I think what I'll do is rejig things to make gcj the preferred jre, but allow others to be manually selected.
I've also found a *major* problem with the database related to gcj. I created a database in an ooo file (not connected through sql or anything) on one computer and copied my file to my laptop. After I upgraded my laptop to ooo 2.0.0-3.2.1, all the dates appeared as 1/1/1970 in the table view and in forms. The dates stored in the file seem to be intact even though they all display as 1/1/1970. If you try to change a date, it turns into 1/1/1970 before being stored in the file. So I downgraded my laptop to the previous ooo 1.9, and discovered that if you use gcj, the same problem occurs. I installed the jpackages for java and switched to Sun's java, and the dates work fine again.
caolanm->caeshmer: Can you log a seperate bug with your specific problem and assign it to the hsqldb module in fedora with a sample openoffice.org-base document which reproduces this sub-problem.
To caolanm: I just posted it, bug # 172305.
reenabled 2.0.0-3.7 rawhide. 2.0.1 proposed for Nov 11, propose to push for fc4 along with that update
*** Bug 174788 has been marked as a duplicate of this bug. ***