Java: Error, version mismatch in JNA library

Product Forums Katalon Studio
,
1

I am working on a project where we want to use Katalon Studio as a single point of running and maintaining tests.
Some of the tests use SikuliX in order to test GUI of native applications, and we aim to write the glue code between the Cucumber features in KS and the Sikulix API in Java.
This glue code is maintained in a separate Java code project at the moment.
The glue code is packaged in a jar with all its dependencies. This jar is then added as Project → External Libraries in Katalon Studio.
When running tests, we experience the following error:

... Reason: java.lang.NoSuchMethodError: org.sikuli.natives.SXUser32.GetKeyboardLayout(I)Lcom/sun/jna/platform/win32/WinDef$HKL; at org.sikuli.script.support.KeyboardLayout.getCurrentLayout(KeyboardLayout.java:743) at org.sikuli.script.support.KeyboardLayout.toJavaKeyCode(KeyboardLayout.java:762) at org.sikuli.script.Key.toJavaKeyCode(Key.java:530) at org.sikuli.script.Key.(Key.java:406) at org.sikuli.script.Region.keyin(Region.java:4965) at org.sikuli.script.Region.type(Region.java:4854) ...

Apparently, this is due to version mismatch in the net.java.dev.jna library.
SikuliX require version 5.x.x of this library. It seems that Katalon has a lower version (4.x.x).

  1. Are there any plans of upgrading Katalon Studio to use newer versions of the jna-library?
  2. Are there any other ways to circumvent this problem?
    We have tried relocating the jna classes in the glue code by using the maven shade plugin. This might work in the general case where there are version mismatches, but in the case of jna, there are too many native dependencies that break.

We are using KS version 7.2.1

Update
I ended up replacing the jna-4.x.jar and the jna-platform-4.x.jar inside
$KATALON_HOME/configuration/resources/lib
with jna-5.x.jar and jna-platform-5.x.jar respectively. Then restarting KS.
Success!!
However, I don’t know if this will hit me with other side effects…

1 Like
2

It may work for a while … until other code will atempt to use the old library … Or not. It depends how the new version of the lib is implemented wrt backward compatibility.
On the other sidee, if you intend to run your project via a certain CI tool, you will have to do the same voodoo again on the runtime engine.
So … best option for your case is to open a feature request asking for the needed lib to be officialy updated. Therefore the dev team will check for potential conflicts and with a bit of luck you can forget about it … until next conflict :slight_smile:

3

Indeed, here perhaps…

1 Like
4

Feature request is submitted: