Home » Newcomers » Newcomers » How to track down jni errors?(Does a "jni not found" when opening a JAR produced on a Mac with a Windows computer mean there is something missing in the Windows computer's Java stuff, or that something was left out by Ec)
| How to track down jni errors? [message #1806117] |
Thu, 02 May 2019 21:48  |
 Patrick Moran
Messages: 141
Registered: March 2018 |
Senior Member |
|
|
  I've redone the setup for Java on my HP running Windows 10 very many times, and nothing has changed the error message: "A JNI error has occurred, please check your installation and try again." I'm not sure what "your installation" refers to. Presumably it is Java JDK and/or JRE and how they are configured on the Windows unit.
Originally, my Mac was running Java 10. I suspected that was the problem, so I uninstalled it and installed the vanilla Java 8. I have made sure that in Preferences "Compiler compliance level" is set to 1.8, and Execution Environments is set for Java SE 8(1.8.0_192 labeled by Eclipse as a "perfect match."
The JAR that I"ve made for my project works on my regular Mac and an older unit that is semi-retired and has a different OS. I had been moving the JAR from computer to computer view my website, but I just tried making a ZIP containing the JAR and support files. That attempt also failed.
I also took an old project made a year or so ago and borrowed its source files, etc. to make a new project on the new Mac. It worked, and I made a JAR for it. That JAR was successful on the HP computer.
I will add two screen shots showing how the new Mac's Eclipse is set up. I need some way to do a better job of troubleshooting.
I would very much appreciate any help or suggestions. There are lots of people having JNI problems, but none having to do with cranky JAR files.
Thanks.
P.S.
The error message.
Java
Virtual Machine Launcher
Error: A JNI retort has occurred. please check your installation and try again.,
[Updated on: Sun, 05 May 2019 18:32] Report message to a moderator |
|
|
| Re: How to track down jni errors? [message #1806593 is a reply to message #1806117] |
Sat, 11 May 2019 08:09  |
Patrick Moran
Messages: 141
Registered: March 2018 |
Senior Member |
|
|
I have found some clear information about JNI. See https://www.math.uni-hamburg.de/doc/java/tutorial/native1.1/concepts/index.html
It would appear that running the Java code in the application on my new Mac fed appropriate instructions to that computer, and that such activity involves calls upon the native-to-this-computer code. The JNI stuff then issues calls to systems operations on the Mac, and that works because whatever version of Java I am using knows how tp issue the right signals to the coding that is deep within the Mac operating Systemj. When the same code is transported via JAR to a computer running another system, e.g., Mac to Windows, there is at some point an instruction coming out of the Java side of things and going into the Windows operations center, but the Windows system does not know how to do whatever the code in the JAR was asking it to do. For instance, on the Mac side, the Java code would, via the JNI stuff, direct the computer to turn on the UV camera. However, on the Windows side and writing for a particular make and model of computer, there may be no way to tell the computer to turn on a camera that it does not have. In a way that is like getting a null pointer error.
So a report of a JNI error doesn't give much specific information about what went wrong. However, it indicates that one should make sure that the version numbers of both the JRE and the JDK are the same. That's probably not the only way for things to go wrong, however.
|
|
|
| Re: How to track down jni errors? [message #1806606 is a reply to message #1806593] |
Sat, 11 May 2019 15:54 |
David Wegener
Messages: 1445
Registered: July 2009 |
Senior Member |
|
|
Your explanation of JNI isn't very accurate. Java programs compile into byte code that is understood by a Java Virtual Machine (JVM). A JVM is kind of like a computer simulator. When the JVM runs a Java program, it reads the the byte code instructions and "translates" them into the machine instructions of the native system that the JVM is running on. The JVM has to be built specifically for the native system. That is why there is a different JVM for Windows, Mac, and Linux.
In order to be useful, the JVM has to provide a portable way to access system resources such as files, network connections, graphics displays. The mechanisms for accessing these resources is tied directly to the native system the JVM is running on. The library/system calls needed to access a file on Windows is different from the library/system calls needed to access a file on a Mac. The JVM uses the Java Native Interface (JNI) to prove access to they system level services. Java methods that use JNI to access services are qualified with the term native (see java.lang.Class.isPrimitive for example). The native qualifier tells the JVM that the code to execute when this method is called exists in an external library. The JVM looks up the specific library call to make based on the fully qualified path name of the method and its arguments. There is a specific naming convention to enable the method to map to a specific external library reference. The JVM includes tools that allow C/C++ header files to be generated from the Java methods that are declared native. This JNI mechanism allows for Java programs to code to a portable method name and allows Java programs compiled on Windows to run on Linux or Mac computers. The Java program invokes the method and the JVM resolves the name to the appropriate external library and invokes the native code in that library.
As mentioned, Java includes native libraries for basic system interaction like read/writing files, making network connections, and drawing on the screen. These are distributed with the JVM as part of the Java Runtime Environment (JRE) whether that is a standalone JRE or included in a Java Development Kit (JDK). In addition, developers can write their own native methods. The developer has to write the native code following the rules of JNI library specification. The developer also has to provide the mechanisms that the JVM needs to locate the libraries and load them at run time. This may be the case for a peripheral such as a camera which includes a Java API library to control the camera. A JNI library would allow the Java code to execute the native code necessary to control the camera.
JNI errors produced by the JVM when a program is run indicate that there was a problem running the code associated with the native method. There can be a number of causes for this. For example, a corrupted JDK/JRE library may not be able to load in which case the JVM isn't able to execute the code. A corrupted operating system may not be able to satisfy a system call made by the native code. For example a call may need to allocate a file on the filesystem. If the filesystem is full, the file allocation can't succeed. For native methods provided by a third party and not directly by the JDK, a third party library or driver may need to be installed for the native code to run. Since native code requires a unique library for each system (Windows, Mac, Linux) a third party Java library will only run on platforms that have a native library written for them.
If you are seeing JNI errors when you run a jar file that works on another system, you are likely either trying to run on a corrupted Java installation or running a jar that has dependencies on a third party JNI library that is compatible/installed on the working system but not on the failing system. A corrupted Java installation will likely have problems running other Java jar files so if only this particular jar file fails, you should look for third party library dependencies.
Version number differences between a JRE and a JDK will rarely cause a JNI error. Version number differences would really only result in a JVM refusing to run code because it was compiled to be compatible with a Java version greater then the maximum version supported by the JVM. A JVM is written to run code that is compatible with a specific Java Language version and all version prior. The Java compiler marks each class file it generates with a version identifier indicating the Java Language specification that the class file complies with. As the JVM loads classes, it looks at this version. If it encounters a class file with a version beyond what it understands, it will throw an exception and likely cause the program to terminate. JNI methods are required to be backwards compatible. As new Java versions are developed, native methods won't be changed but new methods might be added. Java code that invokes the new methods would need to be compiled with the new Java version compiler so the class file would be marked with a new Java version. If the class calling the new method attempted to run on an old JVM, the class version check would reject the class before it would be able to invoke a JNI method. Version differences between JRE and JDK would result in incompatible class version exceptions not JNI errors.
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 14:39:08 GMT 2024
Powered by FUDForum. Page generated in 0.02196 seconds |
] 
Search
Help
Register
Login
Home
