Bug 135479 - LO Complains about missing JDK when accessing any Java functionality, despite recognizing JDK on macOS under Preferences
Summary: LO Complains about missing JDK when accessing any Java functionality, despite...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.2 rc
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.4
Keywords:
: 135644 137767 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-08-05 21:33 UTC by David W. Snow
Modified: 2021-02-08 20:05 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Could not create Java implementation loader (149.61 KB, image/png)
2020-10-06 16:18 UTC, bugzilla
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David W. Snow 2020-08-05 21:33:01 UTC
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..."
Comment 1 Michael Warner 2020-08-06 00:52:02 UTC Comment hidden (obsolete)
Comment 2 Alex Thurgood 2020-08-06 07:30:20 UTC
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
Comment 3 Alex Thurgood 2020-08-06 08:14:40 UTC
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
Comment 4 Alex Thurgood 2020-08-06 08:19:55 UTC
(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.
Comment 5 [REDACTED] 2020-08-06 11:12:23 UTC
(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).
Comment 6 [REDACTED] 2020-08-06 11:22:59 UTC
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)
Comment 7 Alex Thurgood 2020-08-06 13:27:40 UTC
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.
Comment 8 Alex Thurgood 2020-08-06 13:28:33 UTC
@Stephan : any ideas what might be happening here ?
Comment 9 Alex Thurgood 2020-08-06 13:33:26 UTC
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).
Comment 10 Stephan Bergmann 2020-08-06 15:02:11 UTC
From the comments it remains unclear whether or not JRE 14 works with LO 6.4.
Comment 11 DavidO 2020-08-13 18:13:20 UTC
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
Comment 12 Stephan Bergmann 2020-08-14 19:16:45 UTC
(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.)
Comment 13 Marc Grober 2020-08-14 20:28:15 UTC
I can confirm that LO6.x has had no problem working with Oracle Java 14.x.
Comment 14 Marc Grober 2020-08-14 21:56:01 UTC
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.
Comment 15 Marc Grober 2020-08-14 22:13:26 UTC
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?
Comment 16 Stephan Bergmann 2020-08-18 08:13:24 UTC
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.
Comment 17 Stephan Bergmann 2020-08-18 08:34:31 UTC
(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.
Comment 18 Tor Lillqvist 2020-08-18 08:43:05 UTC
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.
Comment 19 Marc Grober 2020-08-26 16:08:33 UTC
*** Bug 135644 has been marked as a duplicate of this bug. ***
Comment 20 Alex Thurgood 2020-09-23 07:12:06 UTC
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
Comment 21 Tor Lillqvist 2020-09-23 08:06:29 UTC
Potential (trivial) fix at https://gerrit.libreoffice.org/c/core/+/103230 , if somebody could confirm that it helps that would be nice.
Comment 22 Stephan Bergmann 2020-09-23 08:17:48 UTC
(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?
Comment 23 Tor Lillqvist 2020-09-23 08:32:56 UTC
Yes, like the TDF builds are, to use the hardened runtime, as far as I understand.
Comment 24 Stephan Bergmann 2020-09-23 09:12:36 UTC
(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.
Comment 25 Commit Notification 2020-09-23 09:16:28 UTC
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.
Comment 26 Alex Thurgood 2020-09-28 07:45:29 UTC
This change might also fix bug 134754 and duplicates, on macOS 10.13, as that bug has been bibisected back to commit 2c366aae9263dc4115b054fe74b90cabea61fa0b
Comment 27 Marc Grober 2020-09-29 17:02:26 UTC
Since @Tor pushed fix I looked in release notes, and this fix does not appear in release notes...
Comment 28 John Layt 2020-10-05 12:05:50 UTC
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?
Comment 29 bugzilla 2020-10-06 16:15:35 UTC
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
Comment 30 bugzilla 2020-10-06 16:18:38 UTC
Created attachment 166133 [details]
Could not create Java implementation loader
Comment 31 Uwe Altmann 2020-11-09 13:08:47 UTC
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?
Comment 32 Michael Nunes 2020-11-30 01:11:26 UTC
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. :(
Comment 33 Tor Lillqvist 2020-12-01 15:40:21 UTC
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.
Comment 34 Commit Notification 2020-12-01 19:53:32 UTC
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.
Comment 35 Michael Nunes 2020-12-02 01:21:34 UTC
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.
Comment 36 Commit Notification 2020-12-02 10:14:32 UTC
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.
Comment 37 Michael Nunes 2020-12-02 19:20:22 UTC
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.
Comment 38 Tor Lillqvist 2020-12-02 19:43:22 UTC
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.
Comment 39 Michael Nunes 2020-12-02 20:30:32 UTC
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.
Comment 40 Tor Lillqvist 2020-12-02 21:50:05 UTC
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".
Comment 41 Marc Grober 2020-12-03 00:28:08 UTC
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?
Comment 42 Stephan Bergmann 2020-12-03 08:36:55 UTC
(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.)
Comment 43 Michael Nunes 2020-12-03 11:09:34 UTC
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?
Comment 44 Uwe Altmann 2021-01-05 17:11:15 UTC
*** Bug 137767 has been marked as a duplicate of this bug. ***
Comment 45 Marc Grober 2021-02-08 20:05:22 UTC
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?