Update to JavaCPP 1.5.4 and use Loader.Detector.getPlatform to avoid "java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path" message

[yukoba]

Because of bytedeco/javacv#1305 , you have to use javacpp-platform from JavaCPP 1.5.3.
You can avoid java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path message by this.

[saudet]

I think this should download the binaries only for javaCppPlatform instead of all platforms.
@lloydmeta ?

[yukoba]

@lloydmeta
This is not a critical bug, but could you please merge this?

[lloydmeta]

I think this should download the binaries only for javaCppPlatform instead of all platforms.
@lloydmeta ?

To be honest, I haven't really even used javacpp in years, so I'm not sure what is required here. Is this a request to amend this PR or just a general question? or a further enhancement question?

[saudet]

From what I understand, it downloads only one platform specific artifact for each library here:
https://github.com/bytedeco/sbt-javacpp/blob/master/src/main/scala/org/bytedeco/sbt/javacpp/Plugin.scala#L55
But JavaCPP now also comes with "presets" for the base classes for various reasons, but since it's not using the "-platform" artifact for the rest, it shouldn't use it for JavaCPP itself either. We should add something like this:

          val generic = "org.bytedeco" % "javacpp" % javaCppVersion.value classifier ""
          val platformSpecific = javaCppPlatform.value.map { platform =>
            "org.bytedeco" % "javacpp" % javaCppVersion.value classifier platform
          }
          generic +: platformSpecific

Does that make sense?

[yukoba]

@saudet
I tried.

Even if I change to this, all the OS jar files are downloaded to %LOCALAPPDATA%\Coursier\Cache\v1\https\repo1.maven.org\maven2\org\bytedeco\javacpp\1.5.3.

      libraryDependencies ++= {
        if (after1_5_3(javaCppVersion.value)) {
          val generic = "org.bytedeco" % "javacpp" % javaCppVersion.value classifier ""
          val platformSpecific = javaCppPlatform.value.map { platform =>
            "org.bytedeco" % "javacpp" % javaCppVersion.value classifier platform
          }
          generic +: platformSpecific
        } else {
          Seq("org.bytedeco" % "javacpp" % javaCppVersion.value jar)
        }
      },

I think because of this line. I also used javacpp-platform here. But I cannot change it to javacpp here.
https://github.com/yukoba/sbt-javacpp/blob/ec8026f21a9b988b18303a775ccb11622daf9c5e/build.sbt#L26

[saudet]

Yes, that's what I mean, it shouldn't use javacpp-platform, unless we can modify it to filter the dependencies like this: https://github.com/bytedeco/gradle-javacpp#the-platform-plugin

[yukoba]

@saudet
So how can we solve this problem? We cannot use JavaCPP API inside build.sbt.

I cannot write like this.

libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3"
libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3" classifier org.bytedeco.javacpp.Loader.getPlatform

[yukoba]

@saudet
One solution is to copy the org.bytedeco.javacpp.Loader.PLATFORM code to build.sbt.
Do you want this?

def getPlatform: String = {
  val jvmName = System.getProperty("java.vm.name", "").toLowerCase
  var osName = System.getProperty("os.name", "").toLowerCase
  var osArch = System.getProperty("os.arch", "").toLowerCase
  val abiType = System.getProperty("sun.arch.abi", "").toLowerCase
  val libPath = System.getProperty("sun.boot.library.path", "").toLowerCase
  if (jvmName.startsWith("dalvik") && osName.startsWith("linux")) osName = "android"
  else if (jvmName.startsWith("robovm") && osName.startsWith("darwin")) {
    osName = "ios"
    osArch = "arm"
  }
  else if (osName.startsWith("mac os x") || osName.startsWith("darwin")) osName = "macosx"
  else {
    val spaceIndex = osName.indexOf(' ')
    if (spaceIndex > 0) osName = osName.substring(0, spaceIndex)
  }
  if (osArch == "i386" || osArch == "i486" || osArch == "i586" || osArch == "i686") osArch = "x86"
  else if (osArch == "amd64" || osArch == "x86-64" || osArch == "x64") osArch = "x86_64"
  else if (osArch.startsWith("aarch64") || osArch.startsWith("armv8") || osArch.startsWith("arm64")) osArch = "arm64"
  else if (osArch.startsWith("arm") && ((abiType == "gnueabihf") || libPath.contains("openjdk-armhf"))) osArch = "armhf"
  else if (osArch.startsWith("arm")) osArch = "arm"
  osName + "-" + osArch
}

//libraryDependencies += "org.bytedeco" % "javacpp-platform" % "1.5.3"
libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3"
libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3" classifier getPlatform

[saudet]

@saudet
So how can we solve this problem? We cannot use JavaCPP API inside build.sbt.

I cannot write like this.

libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3"
libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.3" classifier org.bytedeco.javacpp.Loader.getPlatform

Why not? What happens?

[saudet]

I'm assuming the libraryDependencies in build.sbt are the dependencies for the plugin itself?
Don't put it there, we don't need it there. Put the platform specific dependencies in Plugin.scala with the rest.

[saudet]

Also, this line here should be changed to Loader.Detector.getPlatform instead of just Loader.getPlatform:
https://github.com/bytedeco/sbt-javacpp/blob/master/src/main/scala/org/bytedeco/sbt/javacpp/Platform.scala#L23
That's probably what is causing the java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path warning message.
See bytedeco/javacpp#393 for details.

[yukoba]

@saudet

I'm assuming the libraryDependencies in build.sbt are the dependencies for the plugin itself?

Yes. It is necessary for this line. sbt-javacpp uses javacpp.
https://github.com/yukoba/sbt-javacpp/blob/ec8026f21a9b988b18303a775ccb11622daf9c5e/src/main/scala/org/bytedeco/sbt/javacpp/Platform.scala#L23

What should we do? We cannot escape from getPlatform.
If @saudet splits getPlatform to a different jar file, sbt-javacpp can use it, and not use javacpp itself.

Also, this line here should be changed to Loader.Detector.getPlatform instead of just Loader.getPlatform:

OK. This is a new API of 1.5.4.

[yukoba]

@saudet
Sorry, I now understand what you want to say.
I updated to 1.5.4 and used the new API Loader.Detector.getPlatform.
This pull request solves everything.

@lloydmeta
Please use the new pull request.

[saudet]

Looks good to me! Thanks

[lloydmeta]

The Scala-side changes LGTM.

Does this need a minor version bump of the SBT plugin ?

[yukoba]

@lloydmeta

Does this need a minor version bump of the SBT plugin ?

Yes. Please.

[lloydmeta]

Thanks. Done and released as 1.17

[yukoba]

@lloydmeta
Thank you.