Closed sourcesync closed 3 years ago
bsteffensmeier
commented
5 years ago When installing jep the java source is compiled based on the JAVA_HOME setting. When running jep it uses the first java found on your PATH. Your JAVA_HOME points to java 12 and your PATH has java 8. You can try setting your PATH to $JAVA_HOME/bin:$PATH or try setting your JAVA_HOME to the locatio of your java 8 installation.
sourcesync
commented
5 years ago OK, I think I fixed it per your suggestion, but same error:
(base) Georges-MBP-2:Packages george$ echo $JAVA_HOME /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/ (base) Georges-MBP-2:Packages george$ which java /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home//bin/java (base) Georges-MBP-2:Packages george$ pip install jep Collecting jep Installing collected packages: jep Successfully installed jep-3.9.0 (base) Georges-MBP-2:Packages george$ jep Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: jep/Run has been compiled by a more recent version of the Java Runtime (class file version 56.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
sourcesync
commented
5 years ago I tried also building locally via "python setup.py install".
Same issue...weird. Is it a CLASS_PATH or dynamic load thing? How could I debug that?
ndjensen
commented
5 years ago 56 is Java 12 and 52 is Java 8, so somehow the jar was still compiled with Java 12. You appear to be on macOS. Please put some prints in the commands/java.py file where it attempts to determine what java home to use. https://github.com/ninia/jep/blob/v3.9.0/commands/java.py#L33 And then run python setup.py clean build and watch for the printouts. I'm guessing the logic is returning a java home found before the env_home = os.environ.get('JAVA_HOME') line and therefore ignoring your JAVA_HOME for the compilation step. Please let us know which return statement you reach in java.py's get_java_home() and what the return value is.
sourcesync
commented
5 years ago Thanks for the suggestion. There is something odd about mac's libexec/javahome business.
If I just set $JAVA_HOME environmental variable and bypass the libexec/javahome business, I can workaround it.
I did this awful hack:
def get_java_home(): global _java_home if _java_home is not None: return _java_home
if False and is_osx():
ndjensen
commented
5 years ago I don't have a mac in front of me. What was /usr/libexec/java_home returning? Regardless, some of that OS X specific build code is very old to support when Apple released a JDK, whereas now Apple has stopped doing that and on a mac you must use Oracle's JDK or OpenJDK. So we may be able to remove that code from the build if no one is building on really old macs and setting JAVA_HOME is sufficient. What year is your mac's model and what version of OS X was originally on it? I don't have a new mac available, but I wonder if /usr/libexec/java_home is even a thing on newer macs.
ndjensen
commented
4 years ago The question for this ticket is do we want to remove where the setup script uses /usr/libexec/java_home to find the java home? Since Jep 3.9.1 the JAVA_HOME environment variable will take precedence over /usr/libexec/java_home. I suggest for Jep 4.0 we remove the custom macOS code since we're not supporting the Apple JDK and setting the environment variable is a reasonable expectation.
ndjensen
commented
3 years ago I took out the old Apple JDK code, I left in the /usr/libexec/java_home stuff for now. https://github.com/ninia/jep/commit/a4716db4cdbd385aca46c90f71cbd83a945562ab
ndjensen
commented
3 years ago Closing as this is fixed in Jep 4.0.
Describe the bug
I installed jep successfully using Anaconda3 pip. When i run "jep" I get a JNI error.
Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: jep/Run has been compiled by a more recent version of the Java Runtime (class file version 56.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
To Reproduce Install via pip. Then run jep.
Expected behavior I expected to see a CLI prompt.
Environment (please complete the following information):
jep in /Users/george/anaconda3/lib/python3.7/site-packages (3.9.0)
Additional context I'm probably being a bonehead. Apologies in advance.