Created attachment 163966 [details]
Opening dialog

This comes on each launch of LO

Created attachment 163967 [details]
LO "finds" an Oracle Java installation (which is not there)

One would presume that LO has detected the Java installation (even though it is OpenJDK)

Created attachment 163968 [details]
Can't access /usr/bin or /usr/local/Caskroom/java/

Can't add the correct path to Java and the runtime environment
Calling java -version works fine

Currently, I use Zotero plugin. It can't be activated.

Created attachment 163969 [details]
Zotero plugin cannot be activated

Created attachment 163970 [details]
due to unaccessible JRE

Comment on attachment 163970 [details]
due to unaccessible JRE

No scientific texts for today

The standard location for Java on macOS is :

/Library/Java/JavaVirtualMachines/

this is where LO looks for a valid Java installation.

Thanks for the hint. Yes, there is a directory with OpenJDK but nevertheless, LO start with the above mentioned dialog.

Tried some more things:

Reboot machine -> no resolution
Deleted Zotero plugin -> resolved the error dialog (reproducably, so I assume the error lies within Zotero plugin or the wrapper mechanism in LO)

As there have been reports on other plugins as well, I assume that LO does have an issue. Nevertheless, I reported the issue to Zotero developers as well.

Maybe you check on your plugin wrapper with JDK 14.

Alex, are you following? What has Zotero with path? Is this bug 135479?

As far as I can tell, the behaviour is independent of any extension. 

I don't have an issue with Zotero 5.0.8.9 and
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 OpenJDK12 in the OS default directory

however, using OpenJDK14 in the OS default directory

causes the missing JRE error message to appear (which is indeed incorrect, as the JDK is detected by LO), but clearly no VM is instantiated - clicking on any of the Zotero plugin buttons in the Writer toolbar fails to produce any tangible result.

The take away from this is that if the JDK version that is installed can not be instantiated for whatever reason (wrong or non-authorised path, buggy JDK version, wrong name compared to that expected by LO's XCU files, etc), then the error message will be displayed.

As I mention above, this works fine for me with Oracle OpenJDK12 in the standard OS system path settings, but not with JDK14. Whether this is the same issue as that reported here is as yet unclear.

Stephan: thought you might be interested in this one since it concerns Java.

Sorry war@rsb.at, 
I did a search and this bug did not pop, so I added the bug at 135644.

I have my Java installed in the "proper" location, Alex. (Library/Java/JavaVirtualMachines)  Naming convention with Oracle Java is jdk-14.0.2.jdk What is the name format for you 12.x installation?  This installation (6.x) also worked with all previous Oracle upgrades (from 8.x) which, since Oracle has nothing posted about any susbtantive changes in 14, and 14 works with 6.x, suggests that this is a 7.x problem?

I presently have installed Oracle 14, 14.0.1, and 14.0.2 (not OpenJava...)

I did a refresh install of 7.0.0 and updated from 14.0.1 to 14.0.2 and nothing helped (including rebooting several times, rofl).

As noted in the bug I filed, I have a concurrent LO6.x running with 14.0.1 without any problem

Re Zotero, Adam Stillman at zotero believes that since zotero requires working java, that the zotero issue (unable to install connector) is a result of LO not identifying a working java.

When LO 7 opens after Two identical error messages, I can check the java menu and ALL java extensions are in fact properly listed

Re zotero discussion, please see: 

https://forums.zotero.org/discussion/84538/zotero-plugin-fails-with-libreoffice-7-0

Re title of bug...
I think it clear that LO7 identifies the existence of all jdks installed ata Library Javaa/JavaVirtualMachines...
However, it appears to be either unable to use them, or is throwing inaccurate error messages, as it indicates that the installed JDKs are "defective".

From what I tested myself and read in different forums (to verify my own results) so far:

LO 6.4.5, OpenJDK 14.0.1, Zotero 5.0.89 installed -> Works OK
LO 7.0.0.3, OpenJDK 14.0.1, Zotero 5.0.89 installed -> Breaks Zotero Plugin

From what I figured in my configuration:

my Java installation refers to /usr/bin/java* which refers to a different installation directory that /Library/Java/...

I could not verify if these two versions are linked somehow. If so, then through an OS mechanism but not through file system links.

Maybe someone more proficient in MacOS internals can verify this.

My next steps would be to link the /Library/Java directory to my JDK and see if this works.

I downloaded Oracle Java 12.0.2, Alex, installed, started LO 7.0.0, received the defective java error message, then opened prefs and selected 12.0.2 as the java version for LO 7.0.0 and it work. Thereupon I installed the zotero connector, and it worked as well.

So, it appears that something about LO 7 has broken something that works in LO 6, or that Oracle has somehow changed something in Java 14 that cause LO 7 to choke because LO 7 does not know how to handle it.

At this point I do not know what the actual code error might be, but considering the rather extensive history of LO's issues with java on Mac, I think the criticality on this should be raised so that we don;t find ourselves running down a blind alley.

It would seem that since whatever check LO does when instantiated on java, that whomsoever was responsible for any changes in that detection code should be able to quickly identify what the problem is.

Also wanted to note that this bug lists AMD architecture. The bug I filed (https://bugs.documentfoundation.org/show_bug.cgi?id=135644) is on a MacBook Pro (Retina, Mid 2012) with 2.6 GHz quad-Core Intel CPU.

(In reply to Timur from comment #11)
> Alex, are you following? What has Zotero with path? Is this bug 135479?

I just looked at that bug and added a comment there...   SInce LO7 will not work with Oracle Java 14 but will work with Oracle Java 12, and LO6 will work with BOTH, it looks like something happened in the start-up code in LO7?

Also, as noted, the bug has nothing to do with Zotero really... Zotero simply rrequires java to communicate, and if LO does not recognize a working java, then zotero won't work with it.

Upgraded to 7.0.1.2
Error still persists

Installed JRE: openjdk 14.0.2 (upgraded today, before 14.0.1)
Java in LO recognised, path: /Library/Java/JavaVirtualMachines/openjdk-14.0.2.jdk/Contents/Home (OK and executable)

I tried with both <https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_osx-x64_bin.tar.gz> available from <http://jdk.java.net/14/> and with <https://download.java.net/java/GA/jdk15/779bf45e88a44cbd9ea6621d33e33db1/36/GPL/openjdk-15_osx-x64_bin.tar.gz> available from <http://jdk.java.net/15/>:  If you unpack those *.tar.gz in /Library/Java/JavaVirtualMachines/, recent LibreOffice 7.0.1.2 finds them just fine on the Advanced options page.  (And with upcoming <https://gerrit.libreoffice.org/c/core/+/103212> "Manually select JDK outside /Library/Java/JavaVirtualMachines on macOS" it will even possible to unpuck those *.tar.gz in some other place, and then manually add them on the Advanced options tab page.)

If you have problems with JDK installations provided by Homebrew, I suspect those have, for some reason, a layout that is not recognized by LibreOffice (see e.g. JvmfwkUtil_isLoadableJVM in jvmfwk/plugins/sunmajor/pluginlib/util_cocoa.mm).  But I at least have no idea about Homebrew, and am not going to install it on my Mac to find out.

(In reply to Stephan Bergmann from comment #22)
> I tried with both
> <https://download.java.net/java/GA/jdk14.0.2/
> 205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_osx-x64_bin.tar.gz>
> available from <http://jdk.java.net/14/> and with
> <https://download.java.net/java/GA/jdk15/779bf45e88a44cbd9ea6621d33e33db1/36/
> GPL/openjdk-15_osx-x64_bin.tar.gz> available from <http://jdk.java.net/15/>:

(Those are the places I found via <http://openjdk.java.net/install/> "How to download and install prebuilt OpenJDK packages: JDK 9 & Later" when searching the Web for OpenJDK on macOS.)

(In reply to Marc Grober from comment #24)
> dmg of 7.0.1.2 still does not work with java 14, but continues to work with
> java 12.

Please be more precise:  What "java 14" did you install how and where, what exactly does not work in LO 7.0.1.2?  And if your scenario is sufficiently different from the scenario outlined in comment 0, please file a new issue instead.

(In reply to Alex Thurgood from comment #26)
> Both OpenJDK14 and OpenJDK15 are recognized under Advanced.
> Irrespective of which one is selected, and the Apply button, pressed, LO
> still complains on startup with the JRE missing error message. Additionally,
> attempting to access any table of an embedded hsqldb ODB file fails with an
> error message that no Java is present.
> 
> Tested on
> 
> Version: 7.0.0.3
> Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
> Threads CPU : 8; OS : Mac OS X 10.15.6; UI Render : par défaut; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: threaded

Is that issue 135479?  Please keep this issue focused on the original problem reported in comment 0, which appears to be related to Homebrew.

Here is some more weird stuff:

I upgraded brew: This eliminated the Java cask and up-(actually down-)graded to a JDK 14.0.1 which is now in the main download position (/usr/local/opt/openjdk) and not in a cask any more.

However: after relinking openjdk in /Library/Java/JavaVirtualMachines LO (7.0.1.2) does not recognise any JRE at all.

It is right there, I can call it from CLI, LO simply does not find it.

@Stefan Bergmann: Re "file a new issue"
So it never gets resolved?

(In reply to war from comment #30)
> I upgraded brew: This eliminated the Java cask and up-(actually down-)graded
> to a JDK 14.0.1 which is now in the main download position
> (/usr/local/opt/openjdk) and not in a cask any more.
> 
> However: after relinking openjdk in /Library/Java/JavaVirtualMachines LO
> (7.0.1.2) does not recognise any JRE at all.
> 
> It is right there, I can call it from CLI, LO simply does not find it.

Whatever you mean with "relinking", but I at least cannot help you with getting your machine into a clean state again anyway.  (All I can do is point out my observations from comment 22 how LO does detect certain OpenJDK installations.  Even if those OpenJDK installations ultimately may not work as expected when selected in recent TDF-provided LO builds, see bug 135479.)

> @Stefan Bergmann: Re "file a new issue"
> So it never gets resolved?

Not sure what you mean.  (In comment 25, I asked Marc Grober, who had provided some unclear information that might or might not be relevant for this issue, to file a new issue for his observations if they are not actually related to this issue.  All in an attempt to keep this issue focused---which generally is a good approach to let an issue eventually get resolved :)

(In reply to Stephan Bergmann from comment #29)
> > Calc: threaded
> 
> Is that issue 135479?  Please keep this issue focused on the original
> problem reported in comment 0, which appears to be related to Homebrew.

Sorry Stephan, my bad, apols, should've checked.

Same here, Stephan...  thought this was 135479 issue. Apologies

(In reply to Stephan Bergmann from comment #31)
> (In reply to war from comment #30)
> > I upgraded brew: This eliminated the Java cask and up-(actually down-)graded
> > to a JDK 14.0.1 which is now in the main download position
> > (/usr/local/opt/openjdk) and not in a cask any more.
> > 
> > However: after relinking openjdk in /Library/Java/JavaVirtualMachines LO
> > (7.0.1.2) does not recognise any JRE at all.
> > 
> > It is right there, I can call it from CLI, LO simply does not find it.
> 
> Whatever you mean with "relinking", but I at least cannot help you with
> getting your machine into a clean state again anyway.  (All I can do is
> point out my observations from comment 22 how LO does detect certain OpenJDK
> installations.  Even if those OpenJDK installations ultimately may not work
> as expected when selected in recent TDF-provided LO builds, see bug 135479.)

"brew link java" links the binaries to the default path (/usr/bin).
The machine is in a clean state. I even tried on a newly setup machine. LO 7.0.1.2 does not find OpenJDK 14 (homebrew or binary download).

If I had a chance to find a log or something to single out the error I would gladly try to help. Lacking this tool, I can only describe what I observe: LO does not find a Java installation that lies right under its eyes. 

> 
> > @Stefan Bergmann: Re "file a new issue"
> > So it never gets resolved?
> 
> Not sure what you mean.  (In comment 25, I asked Marc Grober, who had
> provided some unclear information that might or might not be relevant for
> this issue, to file a new issue for his observations if they are not
> actually related to this issue.  All in an attempt to keep this issue
> focused---which generally is a good approach to let an issue eventually get
> resolved :)

Never mind

Maybe we start from scratch:

When LO starts, where does it look to a JRE?
(I presume the answer is: /Library/Java/JavaVirtualMachines/)

Is this the only place it looks?

What does LO look for there?

I think that these simple to answer questions will help trace down the issue.

(In reply to war from comment #35)
> When LO starts, where does it look to a JRE?
> (I presume the answer is: /Library/Java/JavaVirtualMachines/)

yes

> Is this the only place it looks?

yes

> What does LO look for there?

it looks for JDKs; JREs will be ignored (for further details see the JvmfwkUtil_isLoadableJVM in jvmfwk/plugins/sunmajor/pluginlib/util_cocoa.mm code pointer I had mentioned in comment 22)

Thanks for your help this far.

I understand that Libreoffice checks for a JDK in /Library/Java/JavaVirtualMachines regardless how it came there.

I downloaded the JDK you linked in comment 22 and decompressed it directly into /Library/Java/JavaVirtualMachines.

LO does recognise a JDK 14.0.2 now.

Fine.

Starting LO still brings up the initially mentioned error dialog about a missing JRE (see attachment 163966 [details]).

Zotero plugin still does not work or lets itself load.

So. The issue with Java must lie with Homebrew (I have the suspicion that their mechanism to link a package breaks the search mechanism of LO).

I can continue to narrow down the issue with Zotero.

Thanks for your patience.

I think this issue can be closed.

(In reply to war from comment #37)
> Starting LO still brings up the initially mentioned error dialog about a
> missing JRE (see attachment 163966 [details]).
> 
> Zotero plugin still does not work or lets itself load.
> 
> So. The issue with Java must lie with Homebrew (I have the suspicion that
> their mechanism to link a package breaks the search mechanism of LO).

I rather assume that part of your issue is bug 135479.

Some MacOS JRE work has been done for bug 134754 in 7.0.4. Please retest.

"Please retest" for original issue, comment 37 suggested to close the issue, so setting Needinfo.

What processor do you have? I mean if it's Arm, JRE should be used again from 7.5.0
(see https://bugs.documentfoundation.org/show_bug.cgi?id=151545).

Anyway don't hesitate to provide feedback with recent LO versions 7.3.6 or brand new 7.4.2

Dear war,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp