[Octave-bug-tracker] [bug #40111] support runtime selection of Java with JAVA_HOME on Linux and Unix systems

[Philip Nienhuis]

Follow-up Comment #30, bug #40111 (project octave):

After trying the fix I'm a bit confused.
Sorry for the long story below.

On my desktop with only 64-bit Java installation (10.0.1) it works now with a
64-bit Octave ("--enable-windows-64" configure option).

On my laptop with both a 32- and a 64-bit Java JRE it is very different:

* It didn't work at first (with "--enable-64" configure option). An older
64bit octave binary (June 12) I built myself works fine with Java however.
(That older binary is obviously from before the recent round of Java fixes).
(FYI I simply tried the "javaclasspath" command.)

* I first uninstalled both Javas, then reinstalled 64bit Java 8 JRE update 162
(that I had lying around)
==> dev Octave runs fine with it, the older binary too. So apparently the
initial 64bit Java installation was clobbered up.

* Then I also installed the 32bit Java 8 JRE update 162 (was lying around as
well)
==> dev octave doesn't run with it anymore, says "..could not find library ..
blah blah ...".
==> binary from June 12 still works

So I downloaded the 32bit 4.4.0 installer from ftp.gnu.org
==> works fine with Java.

The Java call you mentioned only returns the Java version but not the Java
"bit width".
So I simply renamed the Java JRE install directories by prepending them in
turn with an underscore to verify that the older 32bit Octave automatically
invoked the 32bit Java but couldn't work with the 64bit one, and the older
64bit Octave automatically invoked the 64bit one but couldn't work with the
32bit Java.

Experimenting with JAVA_HOME did help however. It made the dev Octave invoke
64-bit Java.
Pointing JAVA_HOME to the 32-bit Java also worked but of course I got "library
open failed" (due to no matching jvm.dll).
Then, pointing JAVA_HOME back to the proper place showed that Octave got mixed
up: "could not find library or dependencies".
That suggests that apparently Octave keeps leaning on the last location where
it finds a (any) jvm.dll; that's fine at first sight but IMO it should also
check that that jvm.dll really works.

FYI:
In the Windows registry I only see the reference to the 64-bit Java
installation (..\Program Files\.. rather than ..\Program Files (X86)\..).
And system("java -version") invokes the 64-bit Java executable. Could be due
to the search path, however, maybe the 32bit java is after the 64bit one.
All in all I'm a bit surprised that the older 32-bit octave does find the
proper Java "bit width" installation, as it isn't referred to in the registry
- AFAICS that is.

My conclusions;
* JAVA_HOME selection works on Windows but IMO also needs to check that the
jvm.dll is a proper one.
* (that's where I get confused) the 'auto-selection' of the proper Java (32 or
64 bit) is now somehow broken, or at least fragile (it did work initially but
not later on). I'm unsure if the 64bit indexing ("--enable-64" vs.
'--enable-windows-64") makes a difference.

I'm too unfamiliar with the deeper Java intricacies, be it on windows or
Linux, to dig further and/or help out.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40111>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/