[Octave-bug-tracker] [bug #54219] Dynamic detection of JVM on macOS

[Andrew Janke]

Follow-up Comment #3, bug #54219 (project octave):

> Combine this effort with bug #40111, meaning a patch or series of patches
that addresses JAVA_HOME detection on all Unix and GNU systems?

That sounds good. I'll pull its considerations into my next patch.

> Use an m-file function callback to do the filesystem logic part of deriving
the full file name of the libjvm.so/libjvm.dylib from JAVA_HOME? See for
example the m-file code I posted at bug #40111.

I dunno. It's like five lines of C++ code; doesn't seem worth splitting it up
for just that. I'll defer to your wishes, thought.

> Separate the library reorganization aspects / new functions necessary, if
they are necessary, from the Java changes as distinct changes.

Sure. I can do this by just putting all the new run_command stuff into
libinterp instead of liboctave. Will work up a revised patch today.

> What version of Java are you testing with? Does Java on macOS still have a
"$JAVA_HOME/jre/lib" directory? On GNU/Linux that is now just
"$JAVA_HOME/lib". 


* 1.8.0_171, x86_64:    "Java SE
8"      /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home
* 1.8.0_141, x86_64:    "Java SE
8"      /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home
* 1.7.0_79, x86_64:     "Java SE
7"      /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home

You're right; it changed in JDK 9 on macOS, too. Will add logic to cover
that.

> Is /usr/libexec/java_home a hard-and-fast well-known name that will never
change? Is there some other way to encode or configure the location of that
helper command?

It's well-known: it's been around in that location since 2010, and it has a
man page. As far as I know, it's never been in another location. I don't know
of another way of locating that helper command; I've always just seen people
use hardcoded paths to it.

> Should macOS users just have a system initialization octaverc file that
calls that command and sets the JAVA_HOME environment variable?

Seems a little unfriendly to put the onus of configuring Java detection on the
user, when Octave is capable of doing it itself. Especially because the
versions of Java supported by Octave may change over time with different
versions, so the user would have to do the work of managing the
octave-home/share/octave/version/m/startup/octaverc file for each version.


    _______________________________________________________

Reply to this item at:

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

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