Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Issue when multiple JNA versions end up in the same IDE

Sebatian,

It's not clear why some existing/older installation would need to keep both versions. I know that in the past OSGi incrementally updated the wiring, but a couple of releases ago it stopped doing that and builds new wiring from scratch after updates.  I'm not sure how old the installations are where you are seeing this problem...

Looking at the current duplicates for these bundles, there are cases where both would need to be installed, mostly though because Passage uses and older one and excludes the newer one (probably because is uses oshi which also has that constraint:

Regards,
Ed


On 06.12.2022 15:59, Ratz, Sebastian via cross-project-issues-dev wrote:

Hi,

 

If multiple versions of com.sun.jna and com.sun.jna.platform end up in the same Eclipse installation, this can result in errors like the following, which we have seen recently:

 

java.lang.LinkageError: loader constraint violation: when resolving interface method 'boolean com.sun.jna.platform.win32.Kernel32.ReadFile(com.sun.jna.platform.win32.WinNT$HANDLE, byte[], int, com.sun.jna.ptr.IntByReference, com.sun.jna.platform.win32.WinBase$OVERLAPPED)' the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @216be7ba of the current class, com/sap/adt/sapgui/ui/internal/win32/embedding/PipeHelper, and the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @1885dc2b for the method's defining class, com/sun/jna/platform/win32/Kernel32, have different Class objects for the type com/sun/jna/ptr/IntByReference used in the signature (com.sap.adt.sapgui.ui.internal.win32.embedding.PipeHelper is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @216be7ba, parent loader 'platform'; com.sun.jna.platform.win32.Kernel32 is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @1885dc2b, parent loader 'platform')

                at com.sap.adt.sapgui.ui.internal.win32.embedding.PipeHelper.readNamedPipe(PipeHelper.java:119)

                at com.sap.adt.sapgui.ui.internal.win32.embedding.WinGuiServerProxy$2.run(WinGuiServerProxy.java:133)

                at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

 

 

This specific IDE contained

com.sun.jna (5.8.0) [jna] -- reference:file:plugins/com.sun.jna_5.8.0.jar -- ACTIVE

com.sun.jna.platform (5.8.0) [jna-platform] -- reference:file:plugins/com.sun.jna.platform_5.8.0.jar – RESOLVED

com.sun.jna (5.8.0.v20210503-0343) [Java Native Access] -- reference:file:plugins/com.sun.jna_5.8.0.v20210503-0343.jar -- ACTIVE

com.sun.jna.platform (5.8.0.v20210406-1004) [Java Native Access Platform] -- reference:file:plugins/com.sun.jna.platform_5.8.0.v20210406-1004.jar – RESOLVED

 

 

5.8.0 is the official maven central version consumed via Tycho target directly from maven and which is currently part of SimRel 2022-09/12: https://download.eclipse.org/releases/2022-09/202209141001/plugins/

5.8.0.v20210503-0343 is an Eclipse Orbit bundle, part of older SimRels: https://download.eclipse.org/releases/2021-12/202112081000/plugins/

 

 

The official one appears to be missing proper uses constraints in the OSGi metadata, which I suspect can lead to this kind of issue. I have opened a bug: https://github.com/java-native-access/jna/issues/1487

 

 

eclipse.exe -clean

was able to resolve this problem in the bug reports we have received.

 

 

Is there something we do in SimRel to prevent this from running into this situation in upgrade scenarios in the first place (other than waiting for the metadata in JNA to be corrected and consume the newer version)?

 

 

Best regards,

Sebastian


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top