Unable to test custom JNI Lib when loading native library

[jilliam]

Hello. I'm trying to create and test a JNI library using pre-built binaries.
First I ran the example and everything worked fine. Then I changed the name of all the packages and classes, from 'greeter' to 'loader' and 'Greeter' to 'Loader', respectively, and the test task shows the error:

> Task :test FAILED

com.example.loader.LoaderTest > testNullLoader FAILED
    java.lang.UnsatisfiedLinkError at LoaderTest.java:20

com.example.loader.LoaderTest > testLoader FAILED
    java.lang.UnsatisfiedLinkError at LoaderTest.java:13

To simplify the code, I removed almost everything inside the sayHello function in the .cpp file and returned the input jstring.

#include "com_example_loader_Loader.h"

#include <cstring>
#include <cstdlib>

static const char * ERROR_STRING = "name cannot be null";

JNIEXPORT jstring JNICALL Java_com_example_loader_Loader_sayHello(JNIEnv * env, jobject self, jstring name_from_java) {
	// Ensure parameter isn't null
	if (name_from_java == nullptr) {
		return env->NewStringUTF(ERROR_STRING);
	}

	// Return result back to Java
	return name_from_java;
}

The jni header file is properly generated in build>>generated>>jni-headers and matches the implementation in the .cpp.

The java class Loader uses the NativeLoader to load the library "jni-greeter" without any problem.
The test fails and shows the UnsatisfiedLinkError when it calls the method sayHello in the test class:

package com.example.loader;

...

public class LoaderTest {
    @Test
    public void testLoader() {
        Loader loader = new Loader();
        String greeting = loader.sayHello("World"); //<--------------------
    }
...

Any idea of what I might be missing would be really appreciated. Thanks in advance!

[lacasseio]

The problem is being unable to locate the shared library. In the process of renaming, I'm assuming the project name may have changed as well which cause the final library name to be wrong. You can double check the hypothesis by looking inside the build/libs/main directory. The line here: NativeLoader.loadLibrary(Greeter.class.getClassLoader(), "jni-greeter"); assume the library to be named jni-greeter.dll or libjni-greeter.so or libjni-greeter.dylib (base on the OS family). The name is derived from the project name. You can override the name by using library.variants.configureEach { it.baseName = 'jni-greeter' } (there are quality-of-life changes that are coming that allow modifying the base name directly on the library, e.g. library.baseName = 'jni-greeter' but those are not released yet).

[jilliam]

Inside the build/libs directory I have the two .jar files, one with the shared library (libjni-greeter.so) and the other with the bytecode version of Loader and NativeLoader. This Loader class is loading
NativeLoader.loadLibrary(Loader.class.getClassLoader(), "jni-greeter");, as in the source file.

For my sample code, I'm using the "jni-greeter" library, just to have a running version. I tried loading my own shared library, but since it didn't work, I went back to using the jni-greeter.
So in that case, should I still have to override the baseName? I added the line and it didn't change anything.

On the other hand, if I change the name of the library in the NativeLoader.loadLibrary function to a non existing .so, it throws the error when calling the constructor (as expected):

> Task :test FAILED

com.example.loader.LoaderTest > testNullLoader FAILED
    java.lang.ExceptionInInitializerError at LoaderTest.java:19
        Caused by: java.lang.NullPointerException at LoaderTest.java:19

com.example.loader.LoaderTest > testLoader FAILED
    java.lang.NoClassDefFoundError at LoaderTest.java:12

I would think that in the initial code it is finding the shared library, but maybe not the implementation of the native function or the jni header file?

[lacasseio]

Hmmm, good point. Could you share your sample as it's failing with the unsatisfied link error? It has to be something simple :-( In the past, I did spend a lot of time tracking trivial issues as JNI doesn't give good error messages. Given the mention of .so could you confirm you are on Linux? Also, which JDK version are you using? You can do a simple ./gradlew --version, I assume you don't reconfigure the JDK in the build.

[jilliam]

I'm working in Ubuntu 18.04. For the JDK and gradle version:

------------------------------------------------------------
Gradle 6.2.1
------------------------------------------------------------

Build time:   2020-02-24 20:24:10 UTC
Revision:     aacbcb7e587faa6a8e7851751a76183b6187b164

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.11 (Ubuntu 11.0.11+9-Ubuntu-0ubuntu2.18.04)
OS:           Linux 5.4.0-90-generic amd64

I have created a repository with my sample version here.

Btw, I printed the Java path while testing and it was pointing to the correct location, so library.variants.configureEach { nativeRuntimeFiles.setFrom(prebuiltLibraryFile) } is working fine. I wonder if there is anything else I should configure for running the test, besides the java lib path?

Thanks a lot for taking your time to help me solve this problem!

[lacasseio]

Sorry for the delay in the response. So the issue is actually with how exported methods are named. The error message is correct, I simply misinterpreted it. The prebuilt binaries in the example are built for com.example.greeter.Greeter#sayHello. If we list the symbols on the prebuilt binaries, we can see the following (for macOS):

...
0000000000000bb0 T _Java_com_example_greeter_Greeter_sayHello
...

The encoding here is how JNI expects the native methods to be exported. The generated JNI header from javac usually takes care of the for you. For example, the JNI signature for the rename you performed is: JNIEXPORT jstring JNICALL Java_com_example_loader_Loader_sayHello (JNIEnv *, jobject, jstring); The package, class name and method name participate in the name.

The unsatisfied link exception comes from the fact the function for the native method was not found. Either you recompile the prebuilt binaries or keep the original name. In a real project, you would need to make sure the native method on the Java side matches the exported methods from the prebuilt binaries. I understand the confusion and I should add more documentation around troubleshooting JNI-related issues.

I hope that help you progress in your experimentation.

[lacasseio]

I saw that you also have the native code in there which may be what you were trying to compile. The sample force the usage of the prebuilt binaries by overwriting the nativeRuntimeFiles property:

		def prebuiltLibraryFile = file(getLibraryFilePathFor(targetMachine.operatingSystemFamily))
		nativeRuntimeFiles.setFrom(prebuiltLibraryFile)

To compile the loader.cpp code instead, you will need to make the following 3 changes:
1- Apply the cpp-language plugin. The plugins DSL should look like this:

plugins {
	id 'java'
	id 'dev.nokee.jni-library'
	id 'dev.nokee.cpp-language'
}

2- Change the shared library baseName. Prepend the baseName = 'jni-greeter' line with sharedLibrary and uncomment:

		sharedLibrary.baseName = 'jni-greeter'

In the specific version you are using, baseName property is only available on the shared library which is accessible via the variant.

3- Remove the nativeRuntimeFiles override. Simply comment the line nativeRuntimeFiles.setFrom(...).

That will add the C++ language capability to the project, e.g. C++ sources compilation. It will also force the shared library name to align with the Loader code that loads the shared library: NativeLoader.loadLibrary(Loader.class.getClassLoader(), "jni-greeter");. Finally, it will remove the override so the linked shared library is used instead of the pre-built libraries.

[lacasseio]

I hope you don't mind converting the issue into a discussion which better suits the original request. I'm open for any feedback you may have on this.

[jilliam]

Hi Daniel, thanks a lot for your help :)
I will have a look on this and come back to you, but it might take a few days, since I have a deadline this week.