Loading of libraries slower after update to 1.5.10 (Windows, no longer cached?)

[remcopoelstra]

First off thanks for all your great work. I just updated to 1.5.10 and noticed loading of libraries went from 500ms to 5 seconds in my project, I did a little bit of debugging and I get the impression it has to do with caching, with 1.5.9 I see the following debug messages when I start my app for the first time after deleting the cache (I am creating a FFmpegFrameGrabber here):

Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.javacpp.Loader
Debug: Locking C:\Users\remco\.javacpp\cache before extracting
Debug: Extracting jar:file:/C:/Users/remco/.m2/repository/org/bytedeco/javacpp/1.5.9/javacpp-1.5.9-windows-x86_64.jar!/org/bytedeco/javacpp/windows-x86_64/api-ms-win-crt-locale-l1-1-0.dll
Debug: Loading C:\Users\remco\.javacpp\cache\javacpp-1.5.9-windows-x86_64.jar\org\bytedeco\javacpp\windows-x86_64\api-ms-win-crt-locale-l1-1-0.dll
Debug: Locking C:\Users\remco\.javacpp\cache before extracting
Debug: Extracting jar:file:/C:/Users/remco/.m2/repository/org/bytedeco/javacpp/1.5.9/javacpp-1.5.9-windows-x86_64.jar!/org/bytedeco/javacpp/windows-x86_64/api-ms-win-crt-string-l1-1-0.dll
Debug: Loading C:\Users\remco\.javacpp\cache\javacpp-1.5.9-windows-x86_64.jar\org\bytedeco\javacpp\windows-x86_64\api-ms-win-crt-string-l1-1-0.dll
Debug: Locking C:\Users\remco\.javacpp\cache before extracting
Debug: Extracting jar:file:/C:/Users/remco/.m2/repository/org/bytedeco/javacpp/1.5.9/javacpp-1.5.9-windows-x86_64.jar!/org/bytedeco/javacpp/windows-x86_64/api-ms-win-crt-stdio-l1-1-0.dll
Debug: Loading C:\Users\remco\.javacpp\cache\javacpp-1.5.9-windows-x86_64.jar\org\bytedeco\javacpp\windows-x86_64\api-ms-win-crt-stdio-l1-1-0.dll
Debug: Locking C:\Users\remco\.javacpp\cache before extracting
Debug: Extracting jar:file:/C:/Users/remco/.m2/repository/org/bytedeco/javacpp/1.5.9/javacpp-1.5.9-windows-x86_64.jar!/org/bytedeco/javacpp/windows-x86_64/api-ms-win-crt-math-l1-1-0.dll
Debug: Loading C:\Users\remco\.javacpp\cache\javacpp-1.5.9-windows-x86_64.jar\org\bytedeco\javacpp\windows-x86_64\api-ms-win-crt-math-l1-1-0.dll

...

And with 1.5.10 I see this when running after deleting the cache:

Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.ffmpeg.global.avutil
Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.ffmpeg.global.avutil
Debug: Loading library api-ms-win-crt-locale-l1-1-0
Debug: Loading library api-ms-win-crt-string-l1-1-0
Debug: Loading library api-ms-win-crt-stdio-l1-1-0
Debug: Loading library api-ms-win-crt-math-l1-1-0
Debug: Loading library api-ms-win-crt-heap-l1-1-0
Debug: Loading library api-ms-win-crt-runtime-l1-1-0
Debug: Loading library api-ms-win-crt-convert-l1-1-0
...

So it looks like libraries are no longer extracted to the cache. I will try to make some time to look into this deeper but if you have any suggestions that would be greatly appreciated, could it perhaps be that I have to configure caching myself with the new version?

[saudet]

It just looks like the JAR file containing those files is missing from your class path

[remcopoelstra]

Thanks for the suggestion, I will look into this. For the rest everything is working ok, my app is decoding and displaying video frames, Eclipse is also showing javacpp-1.5.10-windows-x86_64.jar under maven dependencies. As a quick test I created a new maven project with javacv-platform 1.5.10 as the only dependency, when I create a FFmpegFrameGrabber in main with debug messages turned on I see the same output.

[saudet]

M2Eclipse is pretty buggy, don't use that

[saudet]

That being said, I am able to reproduce this issue with Maven... Why is it doing that 🤔

[saudet]

Nope, this still occurs with Maven 3.6.3, but only in some cases.

Can you try to call Loader.load(Loader.class) before anything else in your application and see what that gives?

[remcopoelstra]

Yes, if I call Loader.load(Loader.class) first it's working again.

I added some debugging to the findResources(Class cls, String name, int maxLength) to see for which Class it is trying to find the resource int the call: URL url = cls.getResource(name);

When it's working this prints class org.bytedeco.javacpp.Loader, when it's not working this prints class org.bytedeco.ffmpeg.global.avutil.

I will try to see if I can find out why it's passing this class.