pyjnius
pyjnius copied to clipboard
consistently prefer javac or java when searching for libjvm.so
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'
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.
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"
Problem has been worked around and there doesn't seem any interest in several years. Closing as stale.