If you run Mac OS X 10.8 (no upgrade to previous OS X version!), then there is no pre-installed Java (previously, Apple shipped its own version of Java 6). You are supposed to install Java from Oracle's web site. These days, this gets you a 64-bit Java 7 (current version 7u25) as Java 6 is no longer supported and, more importantly, receives no further security updates. Java 7 for Mac OS X is only available as a 64-bit version. Installing any version of LibO 4.x, including 4.1.0.1 RC, then leads to the situation that LibO cannot find and cannot use the installed Oracle Java 7 (e.g. LibO options - extended does not list it). This leads to a number of problems in LibO, esp. apparent when you hit a LibO functionality that requires/uses a Java runtime. Installing an old Java 6 version is no option, as you willingly would have to accept its unresolved securtity issues. Either LibO cannot work with 64-bit Java on OS X (which then needs to be fixed since there is no longer a supported 32-bit version) or it cannot find the installed Java due to the fact that the Oracle installation is different from Apple's former own Java pre-installations in older Mac OS X versions and LibO relies on this specific environment. Or both are issues. Further note: Installing the JDK (versus the JRE) does not help.
Alex/Roman/Joren: I think you might be interested in this bugtracker. If confirmed, it could be quite bad for LO.
Can confirm this problem. A bug already exists thus setting to DUPE. And yes, this is quite bad for LO. We need a 64-bit LO for this to work. *** This bug has been marked as a duplicate of bug 50022 ***
I REOPENED this bug because: While the problem with the LO-Java7 interface (to be changed from Java6 i/f) is indeed a duplicate of bug 50022, the MAJOR problem is that on Mac OS X 10.8, only a 64bit version of Java7 is available - possibly requiring a 64bit version of LO. In my humble opinion, this should be classified as a MAB - simply because on Mac OS X 10.8 there is currently no (safe) way to run LO with any of its Java functionality.
This is also a problem when using external plugins like LanguageTool (www.languagetool.org). However, this works in AOO, so I don't think the changes needed are really big.
I've found a related issue in AOO bugtracker [1], with is exactly a "copy" of this one. It seems some code has been merged [2] to master, but it's not yet in the 4.1 branch. I think this bug is quite important, also the changes are not really complex, to wait for 4.2 to be released. [1] https://issues.apache.org/ooo/show_bug.cgi?id=121715 [2] http://cgit.freedesktop.org/libreoffice/core/commit/?id=b828a6f494cc90e1a135e7442589679993eb2a5c
xavi: I cherry-picked your patch to review for 4.1 branch, see https://gerrit.libreoffice.org/#/c/5295/
BTW, the commit link is this one, not the one included in the previous comment http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3eded9728647bde4af68b9f3c75a51dc0676fc7
Julient, thanks for adding the patch to Gerrit. However, it seems that the link I add for the commit was wrong: it only contained changes for one file, and the original commit was changing three files. Anyway, I don't really understand how the "cherry picking" system works, and where the different commits I've linked are applied (it seems to me that they're both on trunk, which makes no sense to me)
Xavi: I abandonned the cherry-pick I had done. Tor: I tried to cherry-pick http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3eded9728647bde4af68b9f3c75a51dc0676fc7 but it conflicted with 02864717973c01b055152795ac747aeb9c160169. I'm quite confused about all this because the last patch quoted by Xavi appears in 4.1 branch but also in 4.1.1 and in 4.1.0. Any idea?
Julien, I've just confirmed (in the IRC) that 1) the original AOO patch was changing 3 files 2) someone changed "manually" 2 of those 3 files 3) someone cherrypicked the AOO commit, so it "conflicted" in the files that were already changed (however, they're identical) So the gerrit you previously did was OK, as the other changes are already in the codebase. Is there any chance you reopen the gerrit?
I doubt it makes sense to cherry-pick any more work to 4.1 to make LO work with the 64-bit Oracle Java 7, as TDF is not distributing LO 4.1 as a 64-bit build.
Tor: I'm confused. On the long run LO will be 64-bit on OS X, no?
It can be built so already.
Just my 2c: After reading the previous comments, I'm very much in favor of getting the correct patch (maybe from AOO) in to support Java 7 (64bit). One step after the other and the next step could then be the release of LibO for 64bit Mac OS X
This one might be interesting to you Stephan :-)
We had support for (64-bit) Java 7 already since 02864717973c01b055152795ac747aeb9c160169 (by me) on April 9. It worked at least for me then. AOO implemented it later (and slightly differently), and that was *also* cherry-picked to LibreOffice. But if I see correctly, for instance the change in one of those cherry-picks b828a6f494cc90e1a135e7442589679993eb2a5c adds a line that after my earlier change will be bypassed anyway when building as 64-bit for OS X...
Hi Tor, Thanks for your comments here. Now it's clear what the steps were. I'm trying to help in this bug on behalf of some other people that are not fluent enough in English, but I don't have any Mac so I can't do the testing myself. However, it seems now it doesn't work for any reason, and LibO doesn't detect Java 7 (anymore? as you mention it was doing it in April): you can compare what you see in LibO 4.1 [1] (Catalan) and in AOO 4.0 [1] (Spanish) [1] http://picpaste.com/LibO-java7-tC7xqYJt.png [2] http://picpaste.com/AOO-java7-pInjSKcq.png
Probably should mark this as a duplicate of bug #58663?
(In reply to comment #18) > Probably should mark this as a duplicate of bug #58663? Yes, if the problem in this issue is that LO on Mac does not work with 64 bit JREs (where reportedly no 32 bit JREs are provided any more), then the only reasonable solution we have to fix that is to provide 64 bit builds of LO for Mac. (LO instantiates the JVM in-processes, so it just technically does not work to try make a 32 bit LO work with a 64 bit JRE. This is independent of any problems LO's JRE-detection code might have to find some JRE installations, even of the right bit-ness.) *** This bug has been marked as a duplicate of bug 58663 ***