Oshi: Wrong version of JNA is loaded by relying on Maven transitive dependencies

[antonio-rodriges]

Exception in thread "main" java.lang.NoSuchMethodError: com.sun.jna.platform.win32.WinNT$PSID.createFieldsOrder(Ljava/lang/String;)Ljava/util/List;
at com.sun.jna.platform.win32.WinNT$PSID.(WinNT.java:354)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.proxy.$Proxy0.(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)
at com.sun.jna.Native.loadLibrary(Native.java:415)
at com.sun.jna.platform.win32.Advapi32.(Advapi32.java:70)
at oshi.software.os.windows.WindowsOperatingSystem.enableDebugPrivilege(WindowsOperatingSystem.java:639)
Disconnected from the target VM, address: '127.0.0.1:56285', transport: 'socket'
at oshi.software.os.windows.WindowsOperatingSystem.(WindowsOperatingSystem.java:109)
at oshi.SystemInfo.getOperatingSystem(SystemInfo.java:92)
at org.wikience.chronos.common.monitor.OSAndHWInfoCollector.(OSAndHWInfoCollector.java:22)
at org.wikience.FileStorePerfTest.main(FileStorePerfTest.java:27)

[dbwiddis]

The subject line refers to Hardware/DiskStores but the stack trace shows the error in the initialization of WindowsOperatingSystem.

Based on the error being in createFieldsOrder I suspect this is related to our recent move to JNA 5.0.0 which has new @FieldOrder annotation in the structures (such as PSID). Can you confirm you've updated your dependencies, particularly JNA 5.0.0?

[antonio-rodriges]

I do not have explicit JNA dependencies, I depend on oshi:

    <oshi.version>3.9.1</oshi.version>

    <!-- https://mvnrepository.com/artifact/com.github.oshi/oshi-core -->
    <dependency>
        <groupId>com.github.oshi</groupId>
        <artifactId>oshi-core</artifactId>
        <version>${oshi.version}</version>
    </dependency>


    <!-- https://mvnrepository.com/artifact/com.github.oshi/oshi-json -->
    <dependency>
        <groupId>com.github.oshi</groupId>
        <artifactId>oshi-json</artifactId>
        <version>${oshi.version}</version>
    </dependency>

However, I searched my maven repo and found several JNA artifacts (v 4.1.0, 4.2.2, 4.5.2).
Shouldn't OSHI artifact depend on JNA 5.0.0 so that JNA could be automatically resolved?

[antonio-rodriges]

Please, look at https://mvnrepository.com/artifact/com.github.oshi/oshi-core/3.9.1

Does this mean that OSHI depends on old JNA?

[spyhunter99]

Hmm I was testing this the other night. Works on my machine. Does this machine have any unusually hardware?

[dbwiddis]

The 5.0.0 dependency is in the current SNAPSHOT. But 3.9.1 was released with the earlier dependency to 4.5.2.

Still, the last line in OSHI that's causing the issue is simply calling a method from JNA, which has worked fine since it was put in years ago. Do you have any other dependencies in your project that depend on the earlier versions, and not 4.5.2?

[dbwiddis]

To be clear: OSHI 3.9.1 depends on jna-platform 4.5.2 which in turn depends on jna 4.5.2. One of these dependencies is possibly not being enforced. I'd rerun mvn update and possibly purge old versions.

[spyhunter99]

I'm building off of the head, seams to work OK here. I wonder if it's
other strange window registry setting, group policy or something like that

On Tue, Oct 30, 2018, 9:05 AM dbwiddis [e-mail] wrote:

To be clear: OSHI 3.9.1 depends on jna-platform 4.5.2 which in turn
depends on jna 4.5.2. One of these dependencies is possibly not being
enforced. I'd rerun mvn update and possibly purge old versions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/oshi/oshi/issues/669#issuecomment-434313949, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB4kGS6s5Uoxogfr1XceSI43gC8ur6ICks5uqFyegaJpZM4X_shC
.

[antonio-rodriges]

I have removed all JNA dependencies and reimported the projects.
I have discovered both jna 4.1.0 and jna 4.5.2 appeared after updating, and only jna-platform 4.5.2

Seems like OSHI calls go to jna 4.1.0 since when I delete jna 4.1.0 it throws

Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/jna/Platform
at oshi.SystemInfo.(SystemInfo.java:59)
at org.wikience.FileStorePerfTest.main(FileStorePerfTest.java:27)
Caused by: java.lang.ClassNotFoundException: com.sun.jna.Platform
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 2 more

I will try to seek whether any other artifact depends on jna 4.1.0, but I doubt whether I will find any: my first guess is that OSHI is probably the only artifact using jna.

[dbwiddis]

OSHI's only dependency in the POM is jna-platform 4.5.2 so any further dependency on 4.1.0 is outside OSHI. The oshi-dist project builds using the pom.xml and all transitive dependencies and if you download the zip file here you'll see only the 4.5.2 JNA files in the lib directory.

Your issue looks identical to #422 and similar to #410, #435, and #380. These seemed to be resolved by simply specifying the JNA version as a dependency in the pom. It may be that I should update OSHI's pom.xml to explicitly require the jna version instead of relying on the jna-platform transitive dependency -- or it may be that OSHI doesn't change things and you need that line in your POM...

We had an incompatibility version-wise with springboot reported in #351.

I'd be happy to look at your pom.xml and help you sort out any other artifact that may require an earlier version of JNA.

[dbwiddis]

Regarding my comment above on including the JNA dependency in OSHI, probably a good idea, because of how Maven resolves version numbers of transitive dependencies:

Dependency mediation - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.

"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies. For example, if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0.

The upshot of this is:

1. We should update OSHI to include the jna dependency as well as jna-platform to attempt to mitigate this issue, and
2. You can fix your error by explicitly declaring the jna dependency in your own POM at the top level.

[antonio-rodriges]

Thank you, adding the following dependency just near the OSHI resolved the issue:

    <!-- https://mvnrepository.com/artifact/net.java.dev.jna/jna -->
    <dependency>
        <groupId>net.java.dev.jna</groupId>
        <artifactId>jna</artifactId>
        <version>4.5.2</version>
    </dependency>

[dbwiddis]

Good to hear. Sounds like you had another project with a JNA dependency that ended up first in line. I've just merged a fix to OSHI (next release) that will bump that dependency up one level and hopefully prevent most issues like this again (as long as OSHI is listed first in the user's POM), and you have a workaround until you upgrade!