LibreOffice 6.4 didn't complain and worked fine with OpenJDK from OpenJDK on macOS 10.15. LibreOffice 7.0 RC2 complains. I upgraded from OpenJRE 11 to 14 which is the latest, but still no joy. LO writer still seems to work, but I have no idea what features, other than maybe macros might be broken. For those of us that use LibreOffice Writer for writing books (a commercial activity), this means that we now have to pay Oracle a license fee? I just tested with Oracle's JKD and LibreOffice complains about it. Message: "...The selected JRE is defective. Please select another version or install a new JRE and select it under LibreOffice..."
What path is your JRE installed in?
No repro with Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e Threads CPU : 8; OS : Mac OS X 10.15.5; UI Render : par défaut; VCL: osx Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded and Oracle JDK 12.02
No repro Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e Threads CPU : 8; OS : Mac OS X 10.15.5; UI Render : par défaut; VCL: osx Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Using Oracle JDK community edition 14.02
(In reply to David W. Snow from comment #0) > > this means that we now have to pay Oracle a license fee? Paying a license fee to Oracle for business use of their JDK is independent of using LO Writer. For example, LibreOffice Vanilla, available from the app store, doesn't have any Java functionality included, but still lets you use Writer (and all of the other modules), just as long as you don't try to call any Java functionality. You can install the community edition of Oracle JDK if you want to use Java functionality within LO. The JDK needs to be copied to /Library/Java/JavaVirtualMachines/ in order to be recognized by LO.
(In reply to Alex Thurgood from comment #4) > The JDK needs to be copied to /Library/Java/JavaVirtualMachines/ in order to > be recognized by LO. The issue is _not_ about recognition of the installed JDK. The error demonstrates on usage of the (recognized) java from JDK (e.g. establishing the connection to an embedded HSQLDB).
Repro: Version: 7.0.0.3; Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Mac OS X 10.15.6; UI render: GL; VCL: osx Locale: de-DE (en_GB.UTF-8); UI: en-US; Calc: threaded and using: AdoptOpenJDK 11.0.8 (hotspot) AdoptOpenJDK 14.0.2 (hotspot)
The issue then is with JDK14. I can confirm this by loading an embedded hsqldb ODB file. When I click on the Tables icon of the main Base window, I get an error message about a missing JRE, despite LO recognizing JDK14. If I close the file, set the Java JDK to JDK12, then restart LO, and reload the ODB file, I no longer get an error message.
@Stephan : any ideas what might be happening here ?
My JDK14 version reproducing the issue is: openjdk 14.0.2 2020-07-14 OpenJDK Runtime Environment (build 14.0.2+12-46) OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing) whereas openjdk 12.0.2 2019-07-16 OpenJDK Runtime Environment (build 12.0.2+10) OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing) does not cause an issue for me (no error message as reported by OP).
From the comments it remains unclear whether or not JRE 14 works with LO 6.4.
I am trying to reproduce the problem with Java 14. First start of LibreOffice started with debugger crashed with: [1]. Then I tried to debug it and it just worked as expected. Then I tried it without debugger and it also worked. What I did, I created Database.odb Using Java 8, and then I switched to Java 14. LO was built from HEAD (f6253490c48b1e16becb5baf428ad3505a8ed2e2). [1] http://paste.openstack.org/show/796826
(In reply to DavidO from comment #11) > First start of LibreOffice started with debugger crashed with: [1]. [...] > [1] http://paste.openstack.org/show/796826 From that paste, it neither looks like you started LibreOffice with a debugger, nor that the soffice process crashed? > LO was built from HEAD (f6253490c48b1e16becb5baf428ad3505a8ed2e2). (My suspicion would be that the issue is somehow related to the way the TDF-provided LO is built, but I have not yet come around to looking into it.)
I can confirm that LO6.x has had no problem working with Oracle Java 14.x.
At least on Mac OS 10.15 with Intel quad core CPU: Oracle Java SE 14 has worked with each of the major LO 6.x releases and al Catalina releases. On download and install of LO 7.0.0.3 (via TDF dmg) on system with Oracle Java SE 14, and 14.0.1, the LO threw an error message (TWICE) on start-up advising the existing JDKs were defective. Reinstall of LO 7.0.0.3 and install of Oracle Java SE 14.0.2 had no effect. On install of Oracle Java SE 12.0.2, LO7 found 12.0.2 and worked fine. Efficacy of java functionality determined by using Zotero to install LO connector (this will not work if LO does not "see" a working JDK.
Any idea whether this is limited to MacOS, or whether this is a problem with other OS, and whether it only arises on using TDF bundled versions, or all versions?
What I found so far: I downloaded <https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_osx-x64_bin.tar.gz> via <http://openjdk.java.net/install/index.html> -> <http://jdk.java.net/14/> and unpacked it in /Library/Java/JavaVirtualMachines/ as jdk-14.0.2.jdk/. In all the below versions of LO it is found and can be selected fine under "LibreOffice - Preferences... - LibreOffice - Advanced - Java Options". Where behavior indeed differs is when LO actually tries to make use of Java and instantiate the in-process JVM, e.g. via "Tools - Macros - Run macro...": * TDF <https://www.libreoffice.org/donate/dl/mac-x86_64/6.4.6/en-US/LibreOffice_6.4.6_MacOS_x86-64.dmg> works fine. * TDF <https://www.libreoffice.org/donate/dl/mac-x86_64/7.0.0/en-US/LibreOffice_7.0.0_MacOS_x86-64.dmg> fails with the "JRE Is Defective" error dialog ("LibreOffice requires a Java runtime environment (JRE) to perform this task. The selected JRE is defective. Please select another version or install a new JRE and select it under LibreOffice - Preferences - LibreOffice - Advanced.") When run from the command line, it outputs the following: > $ /Applications/LibreOffice.app/Contents/MacOS/soffice > Error occurred during initialization of VM > Could not reserve enough space in CodeHeap 'non-nmethods' (2496K) > JavaVM: JNI_CreateJavaVM called os::abort(), caught by abort_handler in javavm.cxx > [Java framework] sunjavaplugin.dylibCan not create JavaVirtualMachine, abort handler was called. * My local build of libreoffice-7.0.0.3 (but, unlike the above TDF version, with --enable-dbgutil etc.; whether or not that makes the difference) works fine.
(In reply to Stephan Bergmann from comment #16) > * TDF > <https://www.libreoffice.org/donate/dl/mac-x86_64/7.0.0/en-US/LibreOffice_7. > 0.0_MacOS_x86-64.dmg> fails with the "JRE Is Defective" error dialog > ("LibreOffice requires a Java runtime environment (JRE) to perform this > task. The selected JRE is defective. Please select another version or > install a new JRE and select it under LibreOffice - Preferences - > LibreOffice - Advanced.") When run from the command line, it outputs the > following: > > > $ /Applications/LibreOffice.app/Contents/MacOS/soffice > > Error occurred during initialization of VM > > Could not reserve enough space in CodeHeap 'non-nmethods' (2496K) > > JavaVM: JNI_CreateJavaVM called os::abort(), caught by abort_handler in javavm.cxx > > [Java framework] sunjavaplugin.dylibCan not create JavaVirtualMachine, abort handler was called. Searching the web for that "Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)" message turns up <https://github.com/AdoptOpenJDK/openjdk-build/issues/1130> "MacOS hardened runtime support". It mentions a com.apple.security.cs.disable-executable-page-protection key set to true, a setting which our <https://git.libreoffice.org/core/+/2c366aae9263dc4115b054fe74b90cabea61fa0b%5E%21> "Use a less extreme entitlement for our run-time machine code generation" appears to have dropped from hardened_runtime.xcent.in starting with LO 7.0. So that commit might be related.
Reverting the change to hardened_runtime.xcent.in so that it again will use the more broad entitlement is probably what needs to be done. The use of MAP_JIT in bridges/source/cpp_uno/shared/vtablefactory.cxx likely can stay.
*** Bug 135644 has been marked as a duplicate of this bug. ***
Also confirming same problem with openjdk 15 2020-09-15 OpenJDK Runtime Environment (build 15+36-1562) OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) and Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Potential (trivial) fix at https://gerrit.libreoffice.org/c/core/+/103230 , if somebody could confirm that it helps that would be nice.
(In reply to Tor Lillqvist from comment #21) > Potential (trivial) fix at https://gerrit.libreoffice.org/c/core/+/103230 , > if somebody could confirm that it helps that would be nice. But I assume this is only relevant for builds configured with --enable-macosx-code-signing, right?
Yes, like the TDF builds are, to use the hardened runtime, as far as I understand.
(In reply to Stephan Bergmann from comment #22) > (In reply to Tor Lillqvist from comment #21) > > Potential (trivial) fix at https://gerrit.libreoffice.org/c/core/+/103230 , > > if somebody could confirm that it helps that would be nice. > > But I assume this is only relevant for builds configured with > --enable-macosx-code-signing, right? That is, it will not make much sense for people to test <https://gerrit.libreoffice.org/c/core/+/103230> "tdf#135479: Seems we need the more broad entitlement for Java's sake" in their local --disable-macosx-code-signing builds. And depending on how the nightly builds at <https://dev-builds.libreoffice.org/daily/master/> are configured, testing those once <https://gerrit.libreoffice.org/c/core/+/103230> is submitted to master might not make much sense either. In which case it might make sense if Cloph provided a one-off --enable-macsox-code-signing master test build for people to test with.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/247a5304475b9a045a08cbb5e74aec4b99127511 tdf#135479: Seems we need the more broad entitlement for Java's sake It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This change might also fix bug 134754 and duplicates, on macOS 10.13, as that bug has been bibisected back to commit 2c366aae9263dc4115b054fe74b90cabea61fa0b
Since @Tor pushed fix I looked in release notes, and this fix does not appear in release notes...
We've been experiencing this issue too, but with the AdoptOpenJdk 11.0.8 packages (Oracle 1.8 JDK is fine). Is there anything we can do to help test the fix (if needed)? I tried the nightlies, but the versions before the patch actually work OK, so I assume that's to do with them not being the notarized/hardened versions?
I can confirm this bug since LibreOffice version 7 on macos. LanguageTool extension is not working correctly anymore. On every start-up of LibreOffice I get the message that JRE is defective. During re-installation of LanguageTool extension, I get the message: “Could not create Java implementation loader”. Clean installation of LibreOffice (Version: 7.0.2.2) and clean installation of OpenJDK Runtime Environment (build 15+36-1562) did not solve the problem. The bug still remains. Using a Nightly Build of LibreOffice (Version: 7.1.0.0.alpha0+), now the LanguageTool extension is installed properly again. There are no JRE error message anymore. Not working in: Version: 7.0.2.2 Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Working again in: Version: 7.1.0.0.alpha0+ Build ID: f90500754fac014638214b5e061832b2c518aab6 CPU threads: 8; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded using: openjdk 15 2020-09-15 OpenJDK Runtime Environment (build 15+36-1562) OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) and LanguageTool-5.1.2
Created attachment 166133 [details] Could not create Java implementation loader
Confirming the error for LO 7.0.3 on MacOS 10.15.7 and adoptopenjdk-11.jdk as well as adoptopenjdk-8.jdk (=1.8.0–272). Working with Oracle jdk1.8.0_231.jdk Testing with /daily/libreoffice-7-0/MacOSX-x86_64@tb81-TDF/2020-11-09_09.56.40/ against adoptopenjdk-11.jdk shows no error any more. @Tor: You need more tests? Which ones?
I'm on a MacBook Air M1 with Big Sur 11.0.1 and have installed three different versions of Azul ARM compiled openJDKs as well as AdoptOpenJDK.. % /usr/libexec/java_home -V Matching Java Virtual Machines (4): 16 (arm64) "Azul Systems, Inc." - "Zulu 16.0.65-ea" /Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home 13.0.5.1 (arm64) "Azul Systems, Inc." - "Zulu 13.35.1009" /Library/Java/JavaVirtualMachines/zulu-13.jdk/Contents/Home 11.0.9.1 (arm64) "Azul Systems, Inc." - "Zulu 11.43.1007" /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home 11.0.9.1 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home I've tried the latest versions of LibreOffice publicly available for download including 7.0.3, 6.4.7, and the latest nightly build of 7.1.. Version: 7.1.0.0.beta1+ Build ID: 0c1736f2dff63f2ac4a08c2b0e4c0d9c20d693cb CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded No matter which version of the JDK is selected in preferences in ANY of the LibreOffice versions.. java does not function and errors out. If anyone can help me or if I can help any developers try to solve this problem... please let me know. I really need to create a database for a project I have. :(
The patch mentioned in comment #25 has not been cherry-picked to the 7.0 branch, presumably doing that would help for 7.0. The patch is present in 7.1.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/6edd9b477d0653596b200590e750edbd9aa47c62 tdf#135479: Seems we need the more broad entitlement for Java's sake It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I’ve tried the latest daily build of 7.1... presumably the most bleeding edge version of LO and I can confirm Java still does not function within LO on my MBA M1. The same version of Java (now the only version I have installed) functions within the latest OF. Do you need me to do some sort of troubleshooting to help you out? (In reply to Tor Lillqvist from comment #33) > The patch mentioned in comment #25 has not been cherry-picked to the 7.0 > branch, presumably doing that would help for 7.0. The patch is present in > 7.1.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-7-0-4": https://git.libreoffice.org/core/commit/910acf47bb0c725c88d77d60dea29bc2d26b6783 tdf#135479: Seems we need the more broad entitlement for Java's sake It will be available in 7.0.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I just downloaded the latest daily.. Version: 7.2.0.0.alpha0+ Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Here's my version of java.. % /usr/libexec/java_home -V Matching Java Virtual Machines (1): 11.0.9.1 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home I still cannot open/create a new Base document.. I keep getting the following error.. SQL Status: HY000 No Java installation could be found. Please check your installation. Like I have mentioned previously, I don't have this issue in the currently available for download version of OpenOffice. Not sure what the issue is here? Do you need me to try something specific to help you out?? (In reply to Commit Notification from comment #36) > Tor Lillqvist committed a patch related to this issue. > It has been pushed to "libreoffice-7-0-4": > > https://git.libreoffice.org/core/commit/ > 910acf47bb0c725c88d77d60dea29bc2d26b6783 > > tdf#135479: Seems we need the more broad entitlement for Java's sake > > It will be available in 7.0.4. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback.
Michael, commits to the 7.0 and 7.0.4 branches will of course not change the situation for the master (7.2.0 the moment) branch, you are just confusing the issue by mixing up issues.
Sorry about that. I don't see 7.0.4 available in the daily builds.. all I see is.. LibreOfficeDev_7.0.5.0.0_MacOS_x86-64.dmg 258639324 2020-Dec-02 07:38 Would your patch be included in this version? Thank you. (In reply to Tor Lillqvist from comment #38) > Michael, commits to the 7.0 and 7.0.4 branches will of course not change the > situation for the master (7.2.0 the moment) branch, you are just confusing > the issue by mixing up issues.
Download it and check in LibreOffice > About LibreOffice. Click the "Build" link. It will take you to a web page showing what commits are present. You are looking for the commit with the message "tdf#135479: Seems we need the more broad entitlement for Java's sake".
Are we looking at different bugs? The fix for what appeared to be the bug that was originally complained of addressed JDK>12 on LO>=7 The descriptions noted since the fix suggest there is now a problem with jdk11> Should a new bug be created rather than pursue this one, if indeed the current patch solves the originally posted bug?
(In reply to Marc Grober from comment #41) > Are we looking at different bugs? > The fix for what appeared to be the bug that was originally complained of > addressed JDK>12 on LO>=7 > The descriptions noted since the fix suggest there is now a problem with > jdk11> > Should a new bug be created rather than pursue this one, if indeed the > current patch solves the originally posted bug? (Plus, the fix backported in comment 34 and comment 36 should only be relevant for --enable-macosx-code-signing builds, see comment 22 and comment 23, which the daily builds are probably not, anyway.)
I don’t think the version of the JDK matters any at all so there is no point in differentiating the bug based upon version of jdk. (In reply to Marc Grober from comment #41) > Are we looking at different bugs? > The fix for what appeared to be the bug that was originally complained of > addressed JDK>12 on LO>=7 > The descriptions noted since the fix suggest there is now a problem with > jdk11> > Should a new bug be created rather than pursue this one, if indeed the > current patch solves the originally posted bug?
*** Bug 137767 has been marked as a duplicate of this bug. ***
Just installed LO 7.1.0.3 (https://git.libreoffice.org/core/+log/f6099ecf3d29644b5008cc8f48f42f4a40986e4c) on OSX 10.15.7 LO opens without complaint using Oracle Java 14.0.2 I am going to mark it RESOLVED as the resolution seems to address the origianl descriptions of the bug. If others disagree, how do we differentiate between the resolution of at least one issue, but the continued existence of possibly some other issue?