JNA crashes when trying to load a .dll file from a Windows shared drive

[xinyingho]

I have a Java application that uses VLCj to load libvlc.dll and VLCj uses in turn JNA 4.1.0 to do the interface between Java and native code, and I'm on Windows7 64-bit / Java 64-bit 1.8.0.92 / VLC 64-bit 2.2.3.

My Java application and a portable version of VLC are both installed on the same Windows shared drive. So both must be accessed from UNC-styled paths, e.g. "\<folder>".
My application gives to JNA the relative path of VLC from my Java app, e.g. "vlc2.2.3\App\VLCMediaPlayer\libvlc.dll".

When launching my Java app from a local drive, everything's fine. When doing the same from a Windows shared drive, JNA raises a java.lang.Error throwable telling me that some paths aren't valid. It seems like it's because JNA 4.1.0 can't manage Windows shared drives.

I don't know if there's a newer version of JNA that fixed this?

Here's the full stack trace (the error can be translated from French to English as "the syntax of the filename, of the directory or of the drive is incorrect"):

java.lang.Error: La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte.

at com.sun.jna.Native.open(Native Method)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:171)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.sun.jna.Native.loadLibrary(Native.java:412)
at com.sun.jna.Native.loadLibrary(Native.java:391)
at uk.co.caprica.vlcj.binding.LibVlc.<clinit>(LibVlc.java:115)
at uk.co.caprica.vlcj.version.LibVlcVersion.<clinit>(LibVlcVersion.java:32)
at uk.co.caprica.vlcj.discovery.windows.DefaultWindowsNativeDiscoveryStrategy.onFound(DefaultWindowsNativeDiscoveryStrategy.java:71)
at uk.co.caprica.vlcj.discovery.NativeDiscovery.discover(NativeDiscovery.java:125)
at net.babelsoft.negatron.io.Video.isEnabled(Video.java:46)
at net.babelsoft.negatron.view.control.MediaViewPane2.<init>(MediaViewPane2.java:162)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.reflect.misc.ReflectUtil.newInstance(Unknown Source)
at javafx.fxml.FXMLLoader$InstanceDeclarationElement.constructValue(FXMLLoader.java:1009)
at javafx.fxml.FXMLLoader$ValueElement.processStartElement(FXMLLoader.java:746)
at javafx.fxml.FXMLLoader.processStartElement(FXMLLoader.java:2707)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2527)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2441)
at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2409)
at net.babelsoft.negatron.view.control.SoftwareInformationPane.<init>(SoftwareInformationPane.java:41)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.reflect.misc.ReflectUtil.newInstance(Unknown Source)
at javafx.fxml.FXMLLoader$InstanceDeclarationElement.constructValue(FXMLLoader.java:1009)
at javafx.fxml.FXMLLoader$ValueElement.processStartElement(FXMLLoader.java:746)
at javafx.fxml.FXMLLoader.processStartElement(FXMLLoader.java:2707)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2527)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2441)
at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2409)
at net.babelsoft.negatron.NegatronApp.start(NegatronApp.java:76)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$162(LauncherImpl.java:863)
at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$175(PlatformImpl.java:326)
at com.sun.javafx.application.PlatformImpl.lambda$null$173(PlatformImpl.java:295)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$174(PlatformImpl.java:294)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191)
at java.lang.Thread.run(Unknown Source)

[matthiasblaesing]

I ran this (crude hack to test without CLI):

        try {
            NativeLibrary.addSearchPath(RuntimeUtil.getLibVlcLibraryName(), "..\\..\\..\\Downloads\\vlc-2.2.3\\");

            boolean found = new NativeDiscovery().discover();
            String data = "Version: " + LibVlc.INSTANCE.libvlc_get_version();
            JOptionPane.showConfirmDialog(null, data);
        } catch (Throwable ex) {
            JOptionPane.showConfirmDialog(null, ex.getClass().getName() + "\n\n" + ex.getMessage());
        }

That fails with stock vlcj-3.10.1, so I overrode the jna + jna-platform version to 4.2.2 (and 4.3.0-SNAPSHOT), both versions report the version correctly.

So yes - newer version is better...

I don't know if there's a newer version of JNA that fixed this?

Why didn't you test it? You let me do your work....

[xinyingho]

Deeply sorry about this.
When I replaced JNA 4.1.0 by 4.2.2, I got some compilation errors with VLCj. So before going further, I wanted to know if somebody else knew about this issue.
But seeing how you got it within 2 seconds and now that I looked closer, those compilation errors were indeed minor and can be easily fixed.

I confirm that upgrading JNA fixes everything.

[twall]

The sun JVM has some bugs around long path handling, newer Jna attempts
workarounds when it thinks it's encountered such a failure

On Wednesday, June 1, 2016, xinyingho [email protected] wrote:

Deeply sorry about this.
When I replaced JNA 4.1.0 by 4.2.2, I got some compilation errors with
VLCj. So before going further, I wanted to know if somebody else knew about
this issue.
But seeing how you got it within 2 seconds and now that I looked closer,
those compilation errors were indeed minor and can be easily fixed.

I confirm that upgrading JNA fixes everything.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#666 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAuMrWmM1XkogxYL_29R9oRfdQk__8EXks5qHek0gaJpZM4IryTu
.