[1.0.1] Java: java.lang.UnsatisfiedLinkError --- leave Sikuli stuff in one place and use references to sikuli-java.jar

Please go back to the download page and read carefully especially the stuff mentioning the steps to work with Sikuli version 1.0.1 in IDE's like Eclipse.

In any case, with version 1.0.1, you have to run setup, to get your package jar (sikuli-java.jar in your case).
The libs handling is now automatic and does not need any action.

Take care to purge or make unavailable everything from prior Sikuli versions, especially the libs folder.

Hi RaiMan,

First of all, thanks for your comments. I think I have copied sikuli-java.jar to my eclipse project lib location, I think this is only thing
I may have done differently. I am confusing, why I can't copy the file to the project location? (I will try it tomorrow when I got my company, today is the long weekend.) And by looking at the error, seems it missed some classes in lib. Could you please explain it a little more about what happen for this error?

Thanks.
-Kurt.

1.0.1 now contains all things needed in one jar file including the native libraries, that implement the OpenCV (image search) features.

Nevertheless, at runtime, these native libs have to be accessible in the file system outside the jar. This is now done on the fly, by creating a libs folder in the same directory as the jar resides in and the libs are exported from the jar to this libs folder. So you now can even switch between Java 32-Bit and Java 64-Bit without doing anything with Sikuli.

On Windows additionally one has to take care, that the path to this libs folder is on system path at runtime. This is assured when using the command files runIDE and runScript, but not when programming in Java. I added an additional convenience feature: If on Windows it is detected, that the libs folder is not on system path, the registry is fixed accordingly (but one has to at least logout from Windows or even reboot, to get this active). It is not possible with Java, to modify the system environment at runtime and have this modification active for the same JVM process.

So to keep your system clean and lean, it is strongly recommended, to leave the Sikuli stuff in one place, so everything works fine after setup and a first run of the stuff.

BTW: when programming in Java it is good practice, to only have the stuff in your project, that you are developing. all dependency stuff should be in a repository, assuring, that only one copy exists. Build concepts like Maven optimally support this behavior, but even the basic features of IDE's like Netbeans, Eclipse support dependencies by reference and there is no need to copy dependencies around (and one should not do it for obvious reasons).

Hi RaiMan,

Thanks for your more explanation, it is real great for me to understand it.

Yes, seems I have solved the libs issues now, I have successfully launched the test suite which created by other person against to Flex Flash browser application. It successfully login did some actions also, but seems the test suite has some local dependencies that have done by other person, so I have spent some time to figure out to make it completely work.
I am temporarily marking this as solved in case that I don't have problem, if I do, I will reopen this based on the situation.

Thanks.
-Kurt.

Hi RaiMan,

I could my test suite run when I was using only 64 bit lib with sikuli-java.jar file, but right the new sikuli-java.jar contains both 32bit and 64 bit, so now I got the error and couldn't start my test suite any more, could you let me know how can I solve this?

Please see below.

Thanks.
-Kurt.

C:\Users\kchen\workspace\Automation>ant -f build.xml cinputdata
Buildfile: C:\Users\kchen\workspace\Automation\build.xml

cinputdata:
   [testng] [TestRunner] Running the tests in 'BoardVantage Test' with parallel mode:false
   [testng] [RunInfo] Adding method selector: org.testng.internal.XmlMethodSelector@7e5a9de6 priority: 10
   [testng] org.testng.TestNGException:
   [testng] Cannot instantiate class BVSelenium1.BVRegressionTest
   [testng] at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:37)
   [testng] at org.testng.internal.ClassHelper.createInstance1(ClassHelper.java:372)
   [testng] at org.testng.internal.ClassHelper.createInstance(ClassHelper.java:284)
   [testng] at org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:109)
   [testng] at org.testng.internal.ClassImpl.getInstances(ClassImpl.java:184)
   [testng] at org.testng.internal.TestNGClassFinder.<init>(TestNGClassFinder.java:120)
   [testng] at org.testng.TestRunner.initMethods(TestRunner.java:394)
   [testng] at org.testng.TestRunner.init(TestRunner.java:228)
   [testng] at org.testng.TestRunner.init(TestRunner.java:198)
   [testng] at org.testng.TestRunner.<init>(TestRunner.java:147)
   [testng] at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:508)
   [testng] at org.testng.SuiteRunner.init(SuiteRunner.java:142)
   [testng] at org.testng.SuiteRunner.<init>(SuiteRunner.java:106)
   [testng] at org.testng.TestNG.createSuiteRunner(TestNG.java:1116)
   [testng] at org.testng.TestNG.createSuiteRunners(TestNG.java:1103)
   [testng] at org.testng.TestNG.runSuitesLocally(TestNG.java:955)
   [testng] at org.testng.TestNG.run(TestNG.java:900)
   [testng] at org.testng.TestNG.privateMain(TestNG.java:1182)
   [testng] at org.testng.TestNG.main(TestNG.java:1146)
   [testng] Caused by: java.lang.reflect.InvocationTargetException
   [testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   [testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   [testng] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   [testng] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   [testng] at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:28)
   [testng] ... 18 more
   [testng] Caused by: java.lang.UnsatisfiedLinkError: C:\Sikuli X\libs\Win32Util.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
   [testng] at java.lang.ClassLoader$NativeLibrary.load(Native Method)
   [testng] at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
   [testng] at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
   [testng] at java.lang.Runtime.load0(Runtime.java:770)
   [testng] at java.lang.System.load(System.java:1003)
   [testng] at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)
   [testng] at org.sikuli.script.Win32Util.<clinit>(Win32Util.java:19)
   [testng] at java.lang.Class.forName0(Native Method)
   [testng] at java.lang.Class.forName(Class.java:171)
   [testng] at org.sikuli.script.Env.getOSUtil(Env.java:91)
   [testng] at org.sikuli.script.ScreenHighlighter.init(ScreenHighlighter.java:180)
   [testng] at org.sikuli.script.ScreenHighlighter.<init>(ScreenHighlighter.java:293)
   [testng] at org.sikuli.script.Screen.initBounds(Screen.java:105)
   [testng] at org.sikuli.script.Screen.<init>(Screen.java:117)
   [testng] at BVSelenium1.BVRegressionTest.<init>(BVRegressionTest.java:31)
   [testng] ... 23 more
   [testng] The tests failed.

This caused by in libs dir contains Win32Util.dll file now, before only have WinUtil.dll file, it generated on fly. Is anyway we can generate only 64 bit lib files? because my test suite will look the 32bit first, then use 64bit if nothing else found, I don't know
how to configure it from my test suite, so I want to generate only 64 bit libs.

Thanks.
-Kurt.

Since the new version ONLY has a WinUtil.dll in the 64-Bit branch as well as in the 32-Bit branch and switches the libs on the fly as needed, you seem to have a mix of prior Sikuli version and the new one in this case.

Actually I think the sikuli-java.jar generated the Win32Util.dll file, even I have 64 bit machine, I already have 64 bit lib in place, but when I run java, it generated the Win32Util.dll, even I clean it everytime, and it used the Win32Util.dll instead of WinUtil.dll.

I would like to know how can I prevent from generating the Win32Util.dll file on 64 bit Window machine?

Thanks.
-Kurt.

I got it works finally. The issue was:

I installed the Sikuli IDE and runSetup into the same dir, when during the environment set up, so when run java test, on the fly, it
generated native lib files for Window 32, and for some reason, ant doesn't really differentiate Win32 and Win64, actually it looks win32 lib first, if not win32, it used 64bit, so that is why I have the problem which I couldn't get IDE and Java program works at the
same time. By installing Sikuli-java.jar file into diff dir, then run setup #1 option to install IDE to diff dir, then run command line IDE,
I got both works now.

Thanks.
-Kurt.