Warning: Could not load X: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path

[jpsacha]

I am getting warnings while running JavaCPP 1.5.3 or JavaCPP presets (VideoInput etc) on Windows

Warning: Could not load Loader: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path: [...]

Warning: Could not load Pointer: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path: [...]

Warning: Could not load BytePointer: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path: [...]

where [...] is the system path variable value

The code seems to be working, just the warnings being printed.

Some hints what may be going on?

[saudet]

As explained at bytedeco/javacv#1305 we now need to add a dependency on an artifact containing that library, that is all. All presets have already been updated, so we don't need to do anything special. How are you getting this warning?

[jpsacha]

Based on bytedeco/javacv#1305 discussion, It is not clear to me what dependency should be added.

I updated the flandmark example to use JavaCPP 1.5.3. It illustrates the issue.

• you get first warning when you start SBT from command prompt (javacpp is used by SBT to determine platform to add proper dependencies, see project/plugin.sbt)

Warning: Could not load Loader: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path: ...

• when you do run to start the example you get more warnings, but example is working

Here is the code from SBT configuration (build.sbt) that sets the dependencies:

// Platform classifier for native library dependencies
lazy val platform = org.bytedeco.javacpp.Loader.getPlatform

// @formatter:off
libraryDependencies ++= Seq(
  "org.bytedeco" % "javacv"    % "1.5.3",
  "org.bytedeco" % "flandmark" % "1.07-1.5.3"  classifier "",
  "org.bytedeco" % "flandmark" % "1.07-1.5.3"  classifier platform,
  "org.bytedeco" % "openblas"  % "0.3.9-1.5.3" classifier "",
  "org.bytedeco" % "openblas"  % "0.3.9-1.5.3" classifier platform,
  "org.bytedeco" % "opencv"    % "4.3.0-1.5.3" classifier "",
  "org.bytedeco" % "opencv"    % "4.3.0-1.5.3" classifier platform
)

Do you mean that some additional dependency should be added here?

[saudet]

You're missing this dependency:

 "org.bytedeco" % "javacpp" % "1.5.3" classifier platform

[jpsacha]

That solves part of the problem. Adding the dependency stops warnings after SBT loaded and executes code.

The remaining problem is that platform is determined by calling org.bytedeco.javacpp.Loader.getPlatform - for that SBT project loader depends on javacpp (in project/plugin.sbt), at that point platform is not yet know.

On other hand, Warning: Could not load ... is just a warning and code works. May be the actual problem is with the warning itself - may be it should not be issued?

[saudet]

Right, we don't need the native code for Loader.getPlatform()...

[saudet]

Unless you're OK with unfixing bytedeco/javacv#1305, yes we need that warning/error.

[saudet]

If sbt uses a different class loader for executing build.sbt than the one used to build and execute user code, then we could add a flag to disable the log before calling Loader.getPlatform():
https://github.com/bytedeco/javacpp/blob/master/src/main/java/org/bytedeco/javacpp/tools/Logger.java
Would that be satisfactory?

[jpsacha]

Looks that logging levels are right now hard coded, so it will be good to have flexibility to set them through API.

In case of Loader.getPlatform() it would be great to have an optional parameter, say boolean printWarning that can disable warning for that call.

When Loader.getPlatform() is called it really does not need a native libraries, so most natural way would be to, by default, disable the warning about missing jnijavacpp.

[saudet]

We can't transparently disable the warning without risking to unfix bytedeco/javacv#1305. You're the one who posted it, so I'm sure you wouldn't like that! But I think we can work around the problem by moving the code for Loader.getPlatform() to another class...

[saudet]

Ok, I've added the Loader.Detector class in the last commit above, so try to call Loader.Detector.getPlatform() instead. That will not attempt to load any native libraries.

[jpsacha]

Thanks. It works well with the new Detector. Tested with official snapshot.