Re: Need test of patch for OS X

[Alexander Hansen]

> On May 10, 2016, at 13:05, John W. Eaton <address@hidden> wrote:
> 
> On 05/10/2016 04:00 PM, Alexander Hansen wrote:
> 
>> Getting away from hardcoding the configure-time JVM location and also 
>> getting away from linking it would be ideal if you can swing it.  As would 
>> getting away from using the legacy Java 1.6 Framework.  It’s got a stable 
>> location (apart from having moved between the 2014 and 2015 versions), but 
>> Apple is poised to get rid of it altogether.
>> 
>> Personally, dealing with Java on OS X really annoys me, but I’ll go ahead 
>> and defend it just a bit. :-)
>> 
>> The JDK and associated JVM install on OS X has been vaguely standardized now 
>> as of some point in the Java-1.7 series:
>> 
>> Fionna-3:~ hansen$ /usr/libexec/java_home
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
>> 
>> Apple hasn't decided to clobber that executable yet, so there is still a 
>> reliable way to get at the java Home even if JAVA_HOME isn’t set.
>> 
>> Oracle finally settled on 
>> /Library/Java/JavaVirtualMachines/jdk<major>_<minor>.jdk after a few earlier 
>> hiccups.  There are no guarantees with regard to pre-release 1.9 Javas, of 
>> course.
>> 
>> For whatever inscrutable reason, Oracle’s “just JVM” install for OS X is in 
>> a completely different location:
>> 
>> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
>> 
>> That’s for 10.11.  I don’t have other versions handy right now to check 
>> where they install, and there may be some variation.  I also always have a 
>> JDK installed, so I can’t verify that the runtime Java tools know to point 
>> to that JVM.
> 
> It doesn't really matter where they are installed as long as we can load them 
> dynamically, preferably with the octave_shlib interface, which appears to 
> load other shared library objects (.oct files!) properly on OS X.  If this is 
> possible, then we can provide a way to set the name of the JVM shared object 
> at run time so that Octave can load whatever file you choose.
> 
> jwe
> 
> 

Makes sense. 

I haven’t delved into the details, but one issue might be that .oct files are 
built as what OS X terms as bundles rather than as what it terms as “proper" 
shared libraries, and I believe there are some differences in how the two 
classes of objects can be dynamically opened.

—akh