consistently prefer javac or java when searching for libjvm.so

[cmacdonald]

Google's colab has two confusing things about its java setup:

• firstly, there are two different version of java installed: openjdk8 and openjdk11
• two, javac and java point to the two different versions, respectively

I think there is a bug in the searching of the environment. Firstly, assume no JAVA_HOME is set. env.py searches for the JRE, and finds jdk11.

jnius_jvm_dlopen then uses that on a path connected of java 8.

Explicitly setting the JAVA_HOME env var fixes things.

I'm not sure if this is an intended feature of Google colab (I'm asking google - see https://github.com/googlecolab/colabtools/issues/915). I was wondering if jnius can be less sensitive out of the box?

I'm not sure why env.py deals with full paths, but then returns a relative path from get_jnius_lib_location()?

env.py init - JAVA_HOME is None
get_jre_home found java in /usr/lib/jvm/java-11-openjdk-amd64/
get_jre_home is /usr/lib/jvm/java-11-openjdk-amd64/
get_jre_home found java in /usr/lib/jvm/java-11-openjdk-amd64/
testing /usr/lib/jvm/java-11-openjdk-amd64/jre/lib/amd64/server/libjvm.so
assuming lib/server/libjvm.so
---------------------------------------------------------------------------
SystemError                               Traceback (most recent call last)
<ipython-input-4-f6f8b0301452> in <module>()
      1 
----> 2 import jnius
      3 jnius.__version__

2 frames
/usr/local/lib/python3.6/dist-packages/six.py in __new__(cls, name, this_bases, d)
    825 
    826         def __new__(cls, name, this_bases, d):
--> 827             return meta(name, bases, d)
    828 
    829         @classmethod

jnius/jnius_export_class.pxi in jnius.MetaJavaClass.__new__()

jnius/jnius_export_class.pxi in jnius.MetaJavaClass.resolve_class()

jnius/jnius_env.pxi in jnius.get_jnienv()

jnius/jnius_jvm_dlopen.pxi in jnius.get_platform_jnienv()

jnius/jnius_jvm_dlopen.pxi in jnius.create_jnienv()

SystemError: Error calling dlopen(b'/usr/lib/jvm/java-8-openjdk-amd64/lib/server/libjvm.so': b'/usr/lib/jvm/java-8-openjdk-amd64/lib/server/libjvm.so: cannot open shared object file: No such file or directory'

[tshirtman]

I agree our lookup is a bit convoluted, i did split it into functions to be able to see clearer into it, i think we should be able to simplify it now, i'll have a look into that (unless someone gets to it before me), as version mixups may well be responsible of segfaults in some environments. Thanks for the report.

[cmacdonald]

googlecolab/colabtools#915 has now been fixed. I have checked git and 1.2.1 versions, and both work fine on Colab. I'm agnostic as to whether this can now be closed - checking for javac vs java is "convoluted"

[Julian-O]

Problem has been worked around and there doesn't seem any interest in several years. Closing as stale.