How do I resolve the java.lang.UnsatisfiedLinkError: no opencv_java455 in java.library.path error?

[spectacularcrackers]

I have read through the info docs here and also searched extensively on the internet but could not find a solution that works.

I am trying to create a javaFX application with gradle.

I am using this dependency in my gradle.build file: implementation group: 'org.bytedeco', name: 'javacv-platform', version: '1.5.7'

When I run System.loadLibrary(Core.NATIVE_LIBRARY_NAME);, Core.NATIVE_LIBRARY_NAME returns the correct opencv version (opencv_java455). However, System.loadLibrary("opencv_java455") fails with this error: java.lang.UnsatisfiedLinkError: no opencv_java455 in java.library.path:

What would be the correct way to go about resolving this?

From my digging online, I believe that I might be missing a .dylib file. However, I have no idea how to locate this file or how to point to it correctly. I do not see an opencv_java455.dylib file in the external libraries.

Thanks in advance for your help

Here is some more potentially useful information:
Operating system: MacOS Monterey
M1 chip Macbook pro
Using intelliJ

[saudet]

Make sure Loader.load(opencv_java.class) has been called:
https://github.com/bytedeco/javacpp-presets/tree/master/opencv#documentation

[spectacularcrackers]

@saudet I think that fixed the no opencv_java455 in java.library.path issue. I added that line in my main method before calling System.loadLibrary(Core.NATIVE_LIBRARY_NAME);

However, I am now getting a different java.lang.UnsatisfiedLinkError error: Caused by: java.lang.UnsatisfiedLinkError: no jniopenblas_nolapack in java.library.path:. Do you know of any ways to resolve this?

I looked through this thread: #1435. I do not really understand it though.

I already have requires org.bytedeco.javacv.platform in my module-info.java file. I am also using java 11.

[saudet]

Like I said, you'll need to call Loader.load(opencv_java.class).
Please call Loader.load(opencv_java.class) and everything will work as intended!

[spectacularcrackers]

@saudet Thank you for the quick replies.

Unfortunately, I do not think I am understanding correctly. Where should I call Loader.load(opencv_java.class)?

I have it as the first line of my main method:

However, the java.lang.UnsatisfiedLinkError: no jniopenblas_nolapack in java.library.path: error is now occurring here, before it gets to my System.loadLibrary(Core.NATIVE_LIBRARY_NAME); call.

Caused by: java.lang.UnsatisfiedLinkError: Could not find jniopenblas_nolapack in class, module, and library paths.
	at org.bytedeco.javacpp/org.bytedeco.javacpp.Loader.loadLibrary

[saudet]

Call Loader.load(opencv_java.class) instead of calling System.loadLibrary(Core.NATIVE_LIBRARY_NAME), which should fail, so don't call it.

[saudet]

If you get an error on Loader.load(opencv_java.class) it means that some JAR files are missing from your class path. Please make sure to add all the JAR files to your class path.

[saudet]

If you're trying to use the module path instead of the class path, which might be required by JavaFX, I believe this issue is still opened, yes, but that's a problem with JavaFX, not JavaCV. If you don't really care about using the class or modules paths, you can extract all the JAR files on your system, and set the java.library.path system property to where you extracted everything, and then Loader.load(opencv_java.class) will succeed.

[spectacularcrackers]

Ah, ok. I think it is an issue with JavaFX then. For the JAR files, which ones do I need to extract? Would the javacv-1.5.7.jar file be sufficient or are there others that I need?

[saudet]

Well, at least the "openblas" and "opencv" ones, since you're getting errors loading those, but if you get errors about loading other libraries, that means you'll need those as well!

[spectacularcrackers]

@saudet
ok, thank you so much for your help! I really appreciate it!

[saudet]

Duplicate of #1435

[saudet]

@johanvos Your Gradle plugin for JavaFX seems to be having issues as well...

[johanvos]

@saudet Thanks for letting me know. Our Gradle plugin (https://github.com/openjfx/javafx-gradle-plugin/) suffers from permanent changes in Gradle. It takes lots of time from us to maintain that plugin.
Instead of using gradle, we highly recommend the Maven plugin instead: https://github.com/openjfx/javafx-maven-plugin/ .

@spectacularcrackers can you check if you have the same issue with maven? And perhaps file an issue on the javafx-{maven/gradle}-plugin?

[saudet]

@johanvos BTW, Gradle apparently comes with module support since 7.0, most interestingly the inferModulePath property, see gradle/gradle#890 (comment). It might be worth dropping support for older versions of Gradle and restarting fresh from there.

[HGuillemet]

I'm not used to Gradle, but the reported exception is probably due to the native artifacts (opencv-4.5.5-1.5.7-macosx-arm64.jar and the like) not being readable at run time. For them to be readable when running a modular application, these jars must be listed either:

• on the classpath
• or on the modulepath AND added to the module graph with an --add-modules option.

The JavaFX Maven plugin and its run goal takes all Maven dependencies (which include the native artifacts if you declared a dependency towards javacv-platform with the proper javacpp.platform property) and splits it between the module path and the class path depending if the jar files are recognized as belonging to the module graph or not (are required from your module descriptor or from required modules). Since the native artifacts are normally not required, they end on the classpath where they can be read and the application does run.

I don't know if the JavaFX Gradle plugin behaves similarly, but if it does not, you should either use Maven instead, like @johanvos said, or run your application yourself "manually", for instance by obtaining the dependencies from Gradle, and then run something like:

java -p <ListOfDependencies> --add-modules ALL-MODULE-PATH <YourMainClass>

[HGuillemet]

I have written a wiki page about JavaCPP and JavaFX cohabitation. It doesn't bring direct answers to this issue but tries to explain related things.