Loader.load(opencv_java.class) looking for the entire Path in Windows

[abbasvalliani]

Loading Loader.load(opencv_java.class) takes 10 seconds on windows and on debug enabled, the Loader is searching all possible Paths: For .e.g with org.bytedeco.javac=true, I see the following:

Debug: Failed to load for opencv_cudaimgproc440: java.lang.UnsatisfiedLinkError: no opencv_cudaimgproc440 in java.library.path: [C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin, C:\WINDOWS\Sun\Java\bin, C:\WINDOWS\system32, C:\WINDOWS, C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin, C:\Program Files (x86)\Razer\ChromaBroadcast\bin, C:\Program Files\Razer\ChromaBroadcast\bin, C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler, C:\Prog

It does find the libraries but not sure searching for all possible directories in PATH is the way to go.

        <dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>opencv-platform</artifactId>
            <version>4.4.0-1.5.4</version>
        </dependency>

        <dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>numpy-platform</artifactId>
            <version>1.19.1-1.5.4</version>
        </dependency>

[saudet]

To disable that behavior, set the "java.library.path" system property to an empty string.

[abbasvalliani]

It has no impact. See below:

-Dorg.bytedeco.javacpp.logger.debug=true -Djava.library.path=""

    static {
        log.info("Loading - OpenCV Library");
        String libPath = System.getProperty("java.library.path");
        log.debug("Using java.library.path:{} {}", libPath, (libPath != null) ? libPath.length() : "null");
        try {
            Loader.load(opencv_java.class);
        } catch(Exception e) {
            log.error("Unable to load OpenCV due to", e);
            throw e;
        }
        log.info("Loaded - OpenCV Library");
    }

Shows, the following:

09:48:23.759 INFO a.s.d.s.c.a.c.model.OpenCVModel - Loading - OpenCV Library
09:48:23.759 DEBUG a.s.d.s.c.a.c.model.OpenCVModel - Using java.library.path: 0

But I still see the following in the logs:

Debug: Failed to load for cudart64_110: java.lang.UnsatisfiedLinkError: no cudart64_110 in java.library.path: [C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin, C:\WINDOWS\Sun\Java\bin, C:\WINDOWS\system32, ....

I believe the issue is with the following in Loader.java:

                if (!loadedByLoadLibrary0) {
                    System.loadLibrary(libname);

The System.loadLibrary will use the setting of the running JVM and java.library.path has no impact on it. There needs to be a switch to disable any external paths and System.loadLibrary perhaps.

[saudet]

Yes, we can set the java.library.path system property. You're probably running JavaCPP in a different JVM than Maven.

[abbasvalliani]

It should be in the same JVM.

Right before the Loader.load, I know the java.library.path is empty. The issue is that we need to set a different switch to prevent the code to trigger the System.loadLibrary(libname) because we can't control the path it uses. This should be fixed in the Loader.java class.

mvn -f ....\pom.xml test -Pservice -Dorg.bytedeco.javacpp.logger.debug=true -Djava.library.path=""

[saudet]

Hum, ok, maybe we could hack it something like this way:

                if (!loadedByLoadLibrary0 && System.getProperty("java.library.path", "").length() > 0) {
                    System.loadLibrary(libname);

If this does what you need, please send a pull request to that effect!

[abbasvalliani]

I would recommend a new switch org.bytedeco.javacpp.systemLoadLibrary. We can default it to true for backward compatibility so existing applications do not break. Please let me know if that works.

[abbasvalliani]

Just created a pull request. #456

[abbasvalliani]

Removed the switch. See pull request. #457

if (!loadedByLoadLibrary0 && System.getProperty("java.library.path", "").length() > 0) {
                    System.loadLibrary(libname);
}

[saudet]

BTW, I can't reproduce this issue, works fine here: #456 (comment)