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

[Andrew Janke]

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

                 Summary: Dynamic detection of JVM on macOS
                 Project: GNU Octave
            Submitted by: apjanke
            Submitted on: Sun 01 Jul 2018 01:22:38 PM UTC
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.4.0
        Operating System: Mac OS

    _______________________________________________________

Details:

It would be nice if Octave could dynamically detect the location of the JVM on
macOS, instead of being stuck with the exact path detected at build time. This
would let users upgrade their JDK without having to recompile Octave, and
would support redistributable Octave builds that go to systems with various
versions of the JDK installed.

Here is a patch to do so, using the now-standard '/usr/libexec/java_home'
command, and respecting $JAVA_HOME.

Patch details:

Sorry about moving the I/O stuff around. However, it seems like the Right Way
to do things if I'm going to introduce a C++-level
run_command_and_return_output function that returns C++ objects instead of
octave-values.

This patch:

* Has ov-java.cc's initialize_jvm() detect the JVM location dynamically,
using:
  * $JAVA_HOME if it is set
  *  '/usr/libexec/java_home' when no $JAVA_HOME is set and
'/usr/libexec/java_home' is available
  * Falling back to the build-time detected path if neither of those works
* Adds a C++ level run_command_and_return_output that works like the existing
one in libinterp, but returns a C++ object instead of octave-values, and does
not interact with the Octave frame
* Moves that run_command_and_return_output's dependencies from libinterp to
liboctave (since it seems that's where lower-level non-interpreter-interacting
things like I/O and syscalls go)
* Adds a conditional zlib dependency to liboctave, since some of the I/O
functions require it

Sorry for any code style issues in here: I'm no C++ expert, and I'm relatively
new to the Octave code base.

The crux of the code is this new section in ov-java.cc:


#  if defined (__APPLE__)
      // Use standard /usr/libexec/java_home if available
      if (jvm_lib_path.empty ())
        {
          octave::sys::file_stat libexec_java_home_exists
("/usr/libexec/java_home");
          if (libexec_java_home_exists)
            {
              octave::sys::process_execution_result rslt =
octave::sys::run_command_and_return_output (
                  "/usr/libexec/java_home --failfast --version 1.6+
2>/dev/null");
              if (rslt.exit_status () == 0)
                {
                  std::string output = rslt.stdout_output ();
                  std::string found_path = output.substr (0, output.length() -
1);
                  jvm_lib_path = found_path + "/jre/lib/server/libjvm.dylib";
                }
            }
        }
#  endif


This patch is against stable, because dev is not building for me right now.

I have some failing unit tests under this patch, but they are also failing for
me when I build stable without this patch, so I don't know that they're a
regression.

References:
* http://lists.gnu.org/archive/html/octave-maintainers/2012-12/msg00093.html
(old, pre-/usr/libexec/java_home JVM detection)
* https://savannah.gnu.org/bugs/?40111 (Linux equivalent)
* https://savannah.gnu.org/bugs/index.php?53389 (Windows equivalent)



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sun 01 Jul 2018 01:22:38 PM UTC  Name: dynamic-jvm-detection-01.patch 
Size: 70KiB   By: apjanke

<http://savannah.gnu.org/bugs/download.php?file_id=44475>

    _______________________________________________________

Reply to this item at:

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

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