java lib loading mechanism

[CdeMills]

Hello,

I've looked at the issues around the Java package (see bug #40111). The
problem boils down to loading libjvm.so, which is to be found in a
non-standard library path. Under Windows, "jvm.dll" is found from the
registry; the discussion applies to Unix and MacOs platforms.

Actual solution: determine at compile time its full path and call dlopen()
on a static string whose value is set to this path. The trouble is that this
stops working after an upgrade.

My proposal was to introduce an environment variable containing the full
path of the Java lib, which can be set in the .octaverc before calling any
function from the Java package.

The library path is setup as follows under Fedora21:
/usr/lib/java-openjdk-1.8.0-YYY/lib/server/
where YYY is a version number. In /usr/lib exist two more links to this dir:
/usr/lib/java-openjdk and /usr/lib/java-openjdk-1.8.
Another proposal is to use the relative name "libjvm.so", with, 
1) at compile time: use "-ljvm" and
"-L/usr/lib/java-openjdk-1.8.0/lib/server" as switches
2) at run-time: set "LD_LIBRARY_PATH=/usr/lib/java-openjdk-1.8/lib/server"
before launching octave.
This solution would be less sensitive to system upgrade.

Would it be OK to introduce dynamic linking to the shared lib libjvm.so ?

Regards

Pascal




--
View this message in context: 
http://octave.1599824.n4.nabble.com/java-lib-loading-mechanism-tp4667911.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.