bugGNU Octave - Bugs: bug #54219, Dynamic detection of JVM on macOS

 
 

bug #54219: Dynamic detection of JVM on macOS

Submitted by:  Andrew Janke <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:  Patch Submitted Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.4.0 Operating System:  Mac OS

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 12 Jul 2018 09:13:20 PM UTC, comment #10:

Find a new file "dyn-jvm-detection-v02.tgz" attached which contains my changes exported as Mercurial changesets. I've confirmed the upload went through this time.

Andrew Janke <apjanke>
Thu 12 Jul 2018 07:54:15 PM UTC, comment #9:

Yep, looks like I forgot to hit "Submit Changes" on the upload. I'll re-upload as soon as I'm back at my desktop that has my Octave working copy on it. Sorry.

Andrew Janke <apjanke>
Thu 12 Jul 2018 07:51:07 PM UTC, comment #8:

@Andrew: In comment #7 you said that versions were attached as Mercurial changesets, but I still see only the .patch versions attached to this bug report. Could you verify and re-upload if necessary?

Rik <rik5>
Project Administrator
Tue 03 Jul 2018 09:37:39 AM UTC, comment #7:

I've attached a new version of the patches, done as Mercurial changesets, to make them easier to use.

https://savannah.gnu.org/bugs/download.php?file_id=44482

Andrew Janke <apjanke>
Mon 02 Jul 2018 12:19:27 AM UTC, comment #6:

Okay, I've made a new attempt, broken into three patches. This one keeps everything in libinterp to avoid major reorganization of the I/O classes.

  • dyn-jvm-v02-step-01-oct-proc.patch - adds the C++-level run_command_and_return_output function
  • dyn-jvm-v02-step-02-respect-JAVA_HOME.patch - adds JAVA_HOME support on macOS and Linux, taking priority over the compile-time detected path
  • dyn-jvm-v02-step-03-usr_libexec_java_home-on-macOS.patch - adds /usr/libexec/java_home support on macOS

The new logic handles various 'jre/lib', 'jre/lib/server', 'jre/lib/amd64', 'lib/client', etc variations. Same detection logic is used for paths under JAVA_HOME and /usr/libexec/java_home's output, so they're directly substitutable.

Andrew Janke <apjanke>
Sun 01 Jul 2018 11:26:09 PM UTC, comment #5:

> 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.


But it's not, if you allow libjvm.so or libjvm.dylib to exist under several different directory structures over different versions of Java. Here are all the possibilities on a current Debian system:

  • $JAVA_HOME/jre/lib/amd64/server/libjvm.so
  • $JAVA_HOME/jre/lib/i386/client/libjvm.so
  • $JAVA_HOME/jre/lib/i386/server/libjvm.so
  • $JAVA_HOME/lib/client/libjvm.so
  • $JAVA_HOME/lib/server/libjvm.so
Mike Miller <mtmiller>
Project Administrator
Sun 01 Jul 2018 11:21:27 PM UTC, comment #4:

Maybe I'm just envious that no one has yet come up with a cross-distro standard way of declaring where the default Java installation is on GNU/Linux systems :)

If we keep the /usr/libexec/java_home feature, then I see this as (at least) three patches in a series:

  • reorganize the library for whatever changes are needed to get the text output of a subprocess
  • add code to detect JAVA_HOME in the environment and derive the path to libjvm.so or libjvm.dylib from that
  • add code to call /usr/libexec/java_home if it exists, and use the output in the same manner as JAVA_HOME
Mike Miller <mtmiller>
Project Administrator
Sun 01 Jul 2018 10:26:43 PM UTC, comment #3:

> 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.

Andrew Janke <apjanke>
Sun 01 Jul 2018 10:14:27 PM UTC, comment #2:

I guess my preference would be to keep the call to /usr/libexec/java_home out of Octave, that seems far too specific.

But as part of the Homebrew packaging of Octave, you can install a site startup file, e.g. /usr/share/octave/site/m/startup/octaverc, that runs at startup for all users and uses /usr/libexec/java_home to populate JAVA_HOME, if the user hasn't already set it in their login environment.

Mike Miller <mtmiller>
Project Administrator
Sun 01 Jul 2018 09:47:19 PM UTC, comment #1:

What do you think about the following ideas?

  • Combine this effort with bug #40111, meaning a patch or series of patches that addresses JAVA_HOME detection on all Unix and GNU systems?
  • 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.
  • Separate the library reorganization aspects / new functions necessary, if they are necessary, from the Java changes as distinct changes.

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".

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? Should macOS users just have a system initialization octaverc file that calls that command and sets the JAVA_HOME environment variable?

Mike Miller <mtmiller>
Project Administrator
Sun 01 Jul 2018 01:22:38 PM UTC, original submission:

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:

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:

Andrew Janke <apjanke>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44544:  dyn-jvm-detection-v02.tgz added by apjanke (4KiB - application/gzip)
file #44482:  dyn-jvm-v02-step-01-oct-proc.patch added by apjanke (6KiB - application/octet-stream - new attempt at dynamic JVM detection, broken into steps)
file #44483:  dyn-jvm-v02-step-03-usr_libexec_java_home-on-macOS.patch added by apjanke (2KiB - application/octet-stream - new attempt at dynamic JVM detection, broken into steps)
file #44484:  dyn-jvm-v02-step-02-respect-JAVA_HOME.patch added by apjanke (4KiB - application/octet-stream - new attempt at dynamic JVM detection, broken into steps)
file #44475:  dynamic-jvm-detection-01.patch added by apjanke (70KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-12 apjanke Attached File- => Added dyn-jvm-detection-v02.tgz, #44544
    2018-07-12 rik5 StatusNone => Patch Submitted
    2018-07-02 apjanke Attached File- => Added dyn-jvm-v02-step-01-oct-proc.patch, #44482
        Attached File- => Added dyn-jvm-v02-step-03-usr_libexec_java_home-on-macOS.patch, #44483
        Attached File- => Added dyn-jvm-v02-step-02-respect-JAVA_HOME.patch, #44484
    2018-07-01 apjanke Attached File- => Added dynamic-jvm-detection-01.patch, #44475

    Back to the top


    Powered by Savane 3.3