Bug 135462 - LibreOffice 7.0.0.3 does not recognise JRE installation location at startup other than those in /Library/Java/JavaVirtualMachines/
Summary: LibreOffice 7.0.0.3 does not recognise JRE installation location at startup o...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Java-Runtime-JRE-Warnings
  Show dependency treegraph
 
Reported: 2020-08-05 12:43 UTC by war
Modified: 2020-12-24 12:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Opening dialog (165.29 KB, image/png)
2020-08-05 12:44 UTC, war
Details
LO "finds" an Oracle Java installation (which is not there) (898.99 KB, image/png)
2020-08-05 12:45 UTC, war
Details
Can't access /usr/bin or /usr/local/Caskroom/java/ (414.95 KB, image/png)
2020-08-05 12:47 UTC, war
Details
Zotero plugin cannot be activated (440.45 KB, image/png)
2020-08-05 12:50 UTC, war
Details
due to unaccessible JRE (443.10 KB, image/png)
2020-08-05 12:50 UTC, war
Details

Note You need to log in before you can comment on or make changes to this bug.
Description war 2020-08-05 12:43:28 UTC
Description:
During startup, LO 7.0.0.3 requires a JRE but does not find it.
It cannot be pointed to the correct location of the JRE either (because the Add-Dialog does not allow for general directory searches)

Steps to Reproduce:
1.Install LO 7.0.0.3
2.Start LO
3.Try to install JRE manually

=> Java is installed on the machine (using Homebrew installation, located in /usr/bin)

Actual Results:
JRE is neither recognised (hard coded pointer to ~/Library/Java/... which does not exist) nor can be added (due to dialog that does not allow to enter path manually)

Expected Results:
Either automatic detection of Java or possibility to add path oneself.


Reproducible: Always


User Profile Reset: No



Additional Info:
This breaks extensions as they cannot be activated (java wrapper missing)

Reverting to 6.5.x makes JRE and extensions working again
Comment 1 war 2020-08-05 12:44:11 UTC
Created attachment 163966 [details]
Opening dialog

This comes on each launch of LO
Comment 2 war 2020-08-05 12:45:22 UTC
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)
Comment 3 war 2020-08-05 12:47:24 UTC
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
Comment 4 war 2020-08-05 12:48:56 UTC
Currently, I use Zotero plugin. It can't be activated.
Comment 5 war 2020-08-05 12:50:14 UTC
Created attachment 163969 [details]
Zotero plugin cannot be activated
Comment 6 war 2020-08-05 12:50:45 UTC
Created attachment 163970 [details]
due to unaccessible JRE
Comment 7 war 2020-08-05 12:51:29 UTC
Comment on attachment 163970 [details]
due to unaccessible JRE

No scientific texts for today
Comment 8 Alex Thurgood 2020-08-05 13:48:44 UTC
The standard location for Java on macOS is :

/Library/Java/JavaVirtualMachines/

this is where LO looks for a valid Java installation.
Comment 9 war 2020-08-07 10:08:33 UTC
Thanks for the hint. Yes, there is a directory with OpenJDK but nevertheless, LO start with the above mentioned dialog.
Comment 10 war 2020-08-07 10:27:11 UTC
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.
Comment 11 Timur 2020-08-07 14:16:39 UTC
Alex, are you following? What has Zotero with path? Is this bug 135479?
Comment 12 Alex Thurgood 2020-08-10 14:16:18 UTC
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.
Comment 13 Julien Nabet 2020-08-11 19:55:24 UTC
Stephan: thought you might be interested in this one since it concerns Java.
Comment 14 Marc Grober 2020-08-11 20:27:47 UTC
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
Comment 15 Marc Grober 2020-08-11 20:33:12 UTC
Re zotero discussion, please see: 

https://forums.zotero.org/discussion/84538/zotero-plugin-fails-with-libreoffice-7-0
Comment 16 Marc Grober 2020-08-11 20:35:49 UTC
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".
Comment 17 war 2020-08-13 08:44:17 UTC
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.
Comment 18 Marc Grober 2020-08-14 20:04:31 UTC
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.
Comment 19 Marc Grober 2020-08-14 20:07:34 UTC
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.
Comment 20 Marc Grober 2020-08-14 20:33:35 UTC
(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.
Comment 21 war 2020-09-14 08:37:24 UTC
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)
Comment 22 Stephan Bergmann 2020-09-22 19:31:16 UTC
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.
Comment 23 Stephan Bergmann 2020-09-22 19:34:52 UTC
(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.)
Comment 24 Marc Grober 2020-09-23 06:06:33 UTC Comment hidden (obsolete)
Comment 25 Stephan Bergmann 2020-09-23 06:28:34 UTC
(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.
Comment 26 Alex Thurgood 2020-09-23 07:02:05 UTC Comment hidden (hidden, obsolete)
Comment 27 Alex Thurgood 2020-09-23 07:08:51 UTC Comment hidden (hidden, obsolete)
Comment 28 Alex Thurgood 2020-09-23 07:09:47 UTC Comment hidden (hidden, obsolete)
Comment 29 Stephan Bergmann 2020-09-23 07:19:54 UTC
(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.
Comment 30 war 2020-09-23 10:21:55 UTC
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?
Comment 31 Stephan Bergmann 2020-09-23 12:33:26 UTC
(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 :)
Comment 32 Alex Thurgood 2020-09-23 14:55:44 UTC
(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.
Comment 33 Marc Grober 2020-09-23 16:05:31 UTC
Same here, Stephan...  thought this was 135479 issue. Apologies
Comment 34 war 2020-09-26 09:01:45 UTC
(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
Comment 35 war 2020-09-26 09:11:43 UTC
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.
Comment 36 Stephan Bergmann 2020-09-26 11:00:45 UTC
(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)
Comment 37 war 2020-09-29 06:37:57 UTC
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.
Comment 38 Stephan Bergmann 2020-09-29 06:45:25 UTC
(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.
Comment 39 Justin L 2020-12-24 12:59:43 UTC
Some MacOS JRE work has been done for bug 134754 in 7.0.4. Please retest.