Platform.isWindows()

Hey Bill,

What version of JNA are you using? Try the latest (currently 3.5.1).

I believe that is it, we just downloaded it yesterday.

Regards,Bill

Here is the contents of our Turboactivate folder:

TurboActivate/TurboActivate.datTurboActivate/jna.jarTurboActivate/linux-amd64TurboActivate/linux-i386TurboActivate/mac/libTurboActivate.dylibTurboActivate/win-x64/TurboActivate.dll

This folder is directly below the run directory where our other JAR files are. We have compiled all your other APIs and they are included with our app. We set the static TurboActivate.VersionGUID and TurbaActivate.TurboActivateFolder with the full path to the above folder prior to calling TurboActivate.SetPDetsLocation().

Regards,Bill

We can't reproduce this here. Add a breakpoint on the next line after the IsWindows() call and make sure you're using the latest Java and JNA (download the latest JNA separately from the link I linked to above -- we have an older version in our TurboActivate packages).

In order to isolate the issue, we split out just our main class and the turboactivate classes. Your document says that it looks for the native files in the TurboActivate folder relative to "yourApp.jar". This does not actually seem to be the case. It appears that it looks for that relative to where your Turbo*class files are. Our test structure was:

./myapp.class <--- main class run from here, with "build" in class path (java -cp build Main)

./.build/turboactiivate/ Turbo*.class, all Turboactivate Java classes Turboactivate.dat

./build/turboactivate/mac/libTurboActivate.dylib

In this layout, it wanted the libTurboActivate.dylib to be relative YOUR classes, not where main was executed from. So, we moved it there and it worked. However, it said:

"The product details file "TurboActivate.dat" failed to load. It's either missing or corrupt."

Note that this file is located directly above the "mac" directory. The error message really should specify the exact cause (either if found it corrupt, OR it could not find it and it should show WHERE it was looking).

It would actually be better if the code looked for the native DLL/SO files in PATH, and either looked for the DAT fine in "." or required the application to pass in the full path.

Regards

Now can you give us any clue why we are getting the message:

The product details file "TurboActivate.dat" failed to load. It's either missing or corrupt.

We downloaded the file from your website. It is in the same directory that the "mac" subdirectory is in. Since it is finding the mac subdirectory, why can't it find the DAT file?

imac:temp bill$ ls -lt build/turboactivate/mac/total 3968-rwxr-xr-x 1 bill staff 2031528 Dec 7 07:59 libTurboActivate.dylib

imac:temp bill$ ls -lt build/turboactivate/total 168-rw-r--r--@ 1 bill staff 2002 Dec 7 08:00 TurboActivate.datdrwxr-xr-x 3 bill staff 102 Dec 7 07:59 mac-rw-r--r-- 1 bill staff 482 Dec 7 07:25 BoolRef.class-rw-r--r-- 1 bill staff 549 Dec 7 07:25 COMException.class-rw-r--r-- 1 bill staff 783 Dec 7 07:25 DateTimeException.class-rw-r--r-- 1 bill staff 757 Dec 7 07:25 GUIDMismatchException.class.... (other turbo class files)

Did you call TurboActivate.SetPDetsLocation(); at the top of your app? You should. If you look in the example Java app you'll see we call this.

This solves the crossplatform and Java issues of finding where the "*.jar" is, and telling TurboActivate about it.

If that doesn't work, add breakpoints inside the SetPDetsLocation() function to find out what's messing up.

Edit: It looks like we have a small bug in TurboActivate.java file. In SetPDetsLocation(), change this line...

location = TurboActivateFolder + File.separator + "TurboActivate.dat";

to this:

location = TurboActivateFolder + "TurboActivate.dat";

That should fix your problem.