bugGNU Octave - Bugs: bug #59215, [MXE] and core Octave: Java 15...

 
 

bug #59215: [MXE] and core Octave: Java 15 detection on MS Windows fails

Submitter:  Kai Torben Ohlhus <siko1056>
Submitted:  Fri 02 Oct 2020 02:13:22 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.92 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Oct 2020 08:09:28 AM UTC, comment #20: 

Markus, thanks again for your great patch 👍

I am afraid pushing to stable and wait for OctaveSpace to finish the builds is for me the only way to test. 😓  In this case all went well.


Verified by each installing Java 8 (JRE), 11 (JDK), 15 (JDK) exclusively on a MS Windows 10 Home (v2004) system from <https://www.oracle.com/java/technologies/javase-downloads.html>. Running from Octave 6.0.93 (https://hg.savannah.gnu.org/hgweb/octave/rev/55bdcab3d85b)


usejava ("jvm")
javaMethod ("getProperty", "java.lang.System", "java.version")


I assume other Java versions I consider to not really be relevant, as unsupported by Oracle.

Kai Torben Ohlhus <siko1056>
Group Member
Tue 27 Oct 2020 07:55:00 PM UTC, comment #19: 

I'm a little hesitant to commit a change that is completely untested. But I guess we could always revert it if it causes a lot of trouble.
Pushed here:
https://hg.savannah.gnu.org/hgweb/octave/rev/55bdcab3d85b

It would be good to test if all of these version ranges are still correctly detected:
- Java >= 15
- 15 > Java >= 9
- Java < 9
(One of each range should be enough.)

It is probably ok to install those in parallel and select the respective version by setting JAVA_VERSION to the value of the respective key from the registry.

Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 07:22:06 AM UTC, comment #18: 

Okay, agreed.  I made another clean test on a Java free MS Windows 10 system and for JDK 15 there is indeed no setting of the system PATH variable necessary to use Java from within Octave.

I updated the latest documented installation attempt in Discourse

https://octave.discourse.group/t/install-says-it-cant-find-a-jre-but-i-have-java-version-15-installed/266/10

Your patch (file #49937) looks good to me.  All registry paths would match with my system.  Maybe just go ahead an apply it ("damage" is minimal in MS Windows only), then I can test it tomorrow, when my Buildbots finished 😉

Kai Torben Ohlhus <siko1056>
Group Member
Mon 26 Oct 2020 10:43:32 AM UTC, comment #17: 

IIUC, users don't need to set the "PATH" variable manually. IIRC from tests in the past, I never had to change it.
They can set JAVA_HOME if they want to select a specific version (if multiple versions of Java are installed). AFAICT, that is documented (section "A.4.3 Set up the JVM" in the manual).

Markus Mützel <mmuetzel>
Group administrator
Mon 26 Oct 2020 10:05:38 AM UTC, comment #16: 

Thinking about this bug, maybe Octave should provide better documentation, rather than trying to better guess from the registry.

Even if the user has properly installed Java 8, 15, ... she has to set the PATH variable anyways

https://docs.oracle.com/en/java/javase/15/install/installation-jdk-microsoft-windows-platforms.html#GUID-96EB3876-8C7A-4A25-9F3A-A2983FEC016A

to make Java properly work with Octave.  Am I right with this assumption? 

Thus Octave's attempt to (better) detect Java is going to fail anyhow (without explanation to the hard working user) if the PATH variable is not set properly by her.

If my assumption is right, I would like to improve the documentation

https://octave.org/doc/v5.2.0/Java-Interface.html

and "fix" this more sustainably on that level.

Kai Torben Ohlhus <siko1056>
Group Member
Tue 20 Oct 2020 12:08:36 PM UTC, comment #15: 

With patch applied in mxe on my system, I get:


>> usejava('jvm')

ans = 1
>> version -java

ans = Java 1.8.0_231-b11 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
>> array = javaArray ('java.math.BigDecimal', 1)

array =

<Java object: java.math.BigDecimal[]>


John Donoghue <lostbard>
Group Member
Fri 09 Oct 2020 09:40:06 AM UTC, comment #14: 

@lostbard: Looks good to me.

It would be great if someone could test the patch in comment #11.
With it, it should be possible to automatically detect Java versions older than Java 9, older than Java 15 and Java 15.
Also setting JAVA_HOME should select a specific version of multiple versions of Java that are installed in parallel (no matter which one was installed last).

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 05:10:15 PM UTC, comment #13: 

I pushed a change to mxe to disable the check. We can remove it completely now or at a later date

John Donoghue <lostbard>
Group Member
Thu 08 Oct 2020 02:31:45 PM UTC, comment #12: 

Re comment #5:
@lostbard: I'd also vote for removing that detection and warning entirely from the Windows installer.

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 02:29:43 PM UTC, comment #11: 

The attached patch might work for detecting the JDK 15.

I've done only minimal testing (apart from making sure the compiler doesn't complain) because I don't have Java installed.

(file #49937)

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 12:40:57 PM UTC, comment #10: 

All our detection logic is for Oracle's "reference" Java.

It is already possible (and still will be) to set JAVA_HOME if a user wants to use a version of Java that differs from the registered one (or if there is no registered one). I guess that would also work for OpenJDK.

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 12:30:47 PM UTC, comment #9: 

That won't solve OpenJDK installations (admittedly rare) that AFAIK don't set any registry entries.

Once up and running Octave itself will alert users soon enough when they try some Java-based stuff.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 08 Oct 2020 11:25:19 AM UTC, comment #8: 

Looking at `get_jvm_lib_path_from_registry` in `ov-java.cc`, the logic until now was to search for newer versions first. Only if they can't be found, try older versions.

Would checking the registry values at "HKEY_LOCAL_MACHINE\software\javasoft\jdk" first lead to an error if only(!) older JREs are installed?

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 02:21:06 AM UTC, comment #7: 

Regarding comment #5 and #6, I favor to remove the Java check in mxe-octave entirely.  It confuses users (at least many of my colleagues) and there is no urgent need for a working Java interface when using Octave for numerical tasks.

This would reduce a flood of help requests and bug reports from worried users, installing Octave on Windows for the first time and find themselves a (false) warning they cannot fix themselves as Java is correctly setup on their system.

The small portion of users that really want to use Java on Windows with Octave can be helped more precisely.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 05 Oct 2020 10:24:40 PM UTC, comment #6: 

At first sight it looks good to fix the installer along the lines Kai suggested in comment #3.
But e.g., OpenJDK comes w/o installers and registry settings. So maybe checking for java.exe is a better trick. But the other thing to be checked (isn't done now TTBOMK) would be 32/64 bits Java vs. 32/64-bit Octave. All in all it could get a bit involved :-)

So, if disabling the installer Java check for now is easier I couldn't object.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 05 Oct 2020 12:13:11 PM UTC, comment #5: 

So for the installer part of this, do we want to just disable/remove the java check?

John Donoghue <lostbard>
Group Member
Sun 04 Oct 2020 10:28:40 AM UTC, comment #4: 

Yeah, it seems Windows' unambiguous way to find Java has fallen victim to what looks like "change for the sake of change".
OTOH maybe we've been relying on this mechanism a little too much.

Since some time the JAVA_HOME environment setting also works fine on Windows so there's at least another fall-back option.

FTR, Octave isn't quite the only SW failing to detect newer Java releases.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 02 Oct 2020 11:17:58 PM UTC, comment #3: 

Regarding comment #2, yes exactly.  But Octave and the MXE installer only search in


HKEY_LOCAL_MACHINE\software\javasoft\jre


Which I showed by the screenshots does no longer exist for Java 15 setups on MS Windows :-/

An not too complicated fix might be to extend those searchers to


HKEY_LOCAL_MACHINE\software\javasoft\jdk


after the jre for old Java versions failed.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 02 Oct 2020 07:00:05 PM UTC, comment #2: 

Doesn't Octave use registry settings on Windows to localize Java?

I remember a note by Michael Goffioul (who created the Java package that underlies Octave's Java subsystem) that while Linux rigid and reliable standards for file system layout but no good solution for finding a Java installation, Windows is exactly the opposite.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 02 Oct 2020 02:13:56 PM UTC, comment #1: 








Kai Torben Ohlhus <siko1056>
Group Member
Fri 02 Oct 2020 02:13:22 PM UTC, original submission:  

The Octave’s and MXE's Java checks all look for a runtime environment “JRE” to be installed, but since Java 15 this seems to be no longer available, only an “JDK” development kit.

(reg1.png)

(reg2.png)

(explorer1.png)

(explorer2.png)

Code in Octave

https://hg.savannah.gnu.org/hgweb/octave/file/2219027f5bd4/libinterp/octave-value/ov-java.cc#l550

Code in MXE installer

https://hg.octave.org/mxe-octave/file/tip/tools/makeinst-script.sh.in#l899

Report on Discourse

https://octave.discourse.group/t/install-says-it-cant-find-a-jre-but-i-have-java-version-15-installed/266/10

Kai Torben Ohlhus <siko1056>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49937:  bug59215_java15.patch added by mmuetzel (5KiB - application/octet-stream)
file #49916:  reg1.png added by siko1056 (28KiB - image/png)
file #49917:  reg2.png added by siko1056 (29KiB - image/png)
file #49918:  explorer1.png added by siko1056 (10KiB - image/png)
file #49919:  explorer2.png added by siko1056 (12KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by siko1056 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-29 siko1056 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-27 mmuetzel StatusPatch Reviewed Ready For Test
    2020-10-27 siko1056 Release6.0.90 6.0.92
    2020-10-27 siko1056 StatusNeed Info Patch Reviewed
    2020-10-08 mmuetzel Attached File- Added bug59215_java15.patch, #49937
    2020-10-08 siko1056 StatusNone Need Info
    2020-10-02 siko1056 Attached File- Added reg1.png, #49916
        Attached File- Added reg2.png, #49917
        Attached File- Added explorer1.png, #49918
        Attached File- Added explorer2.png, #49919

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code