Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Dynamic 32-64 bit loading
Dynamic 32-64 bit loading [message #824633] Mon, 19 March 2012 22:22 Go to next message
Adam Fisk is currently offline Adam FiskFriend
Messages: 4
Registered: February 2012
Junior Member
I'd like to be create an SWT jar, let's say for Windows to keep it simple, that would dynamically load the 32 bit native SWT dlls if the JVM is 32 bit and the 64 bit SWT dlls if the JVM is 64 bit.

It seems like someone must have done this before, but it's not clear to me how without patching SWT and doing it the hard way.

Any advice would be much appreciated. Thanks!

-Adam
Re: Dynamic 32-64 bit loading [message #824673 is a reply to message #824633] Mon, 19 March 2012 23:25 Go to previous messageGo to next message
Adam Fisk is currently offline Adam FiskFriend
Messages: 4
Registered: February 2012
Junior Member
It seems like one route could be to remove all native libraries from the jars themselves and swap the 64 bit or 32 bit versions dynamically onto the library path at runtime, with SWT hopefully still loading them no problem.

That would only work if the only difference between the 64 bit and 32 bit SWT versions is in the native code, however. If there are also changes on the Java side, that would be a problem. Does anyone know if the only difference between the 64 bit and 32 bit versions is in the native code?

Thanks.

-Adam
Re: Dynamic 32-64 bit loading [message #824881 is a reply to message #824673] Tue, 20 March 2012 07:23 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 5468
Registered: July 2009
Senior Member
The javacode is different on 32bit an int is used on 64bit a long when
passing pointers from java to native and native to java.

I think the only possibility is that you package your stuff like this:

installdir
+ myapp.jar
+ libs
+ swt-win32.jar
+ swt-win64.jar
+ launcher.bat (build a different classpath depending on the platform)

Another quite interesting solution to the problem is how JavaFX does
approach this. They have a special launcher which simply locates the
JavaFX-Runtime and resets the threads contexts classloader.

Tom

Am 20.03.12 00:25, schrieb Adam Fisk:
> It seems like one route could be to remove all native libraries from the
> jars themselves and swap the 64 bit or 32 bit versions dynamically onto
> the library path at runtime, with SWT hopefully still loading them no
> problem.
>
> That would only work if the only difference between the 64 bit and 32
> bit SWT versions is in the native code, however. If there are also
> changes on the Java side, that would be a problem. Does anyone know if
> the only difference between the 64 bit and 32 bit versions is in the
> native code?
>
> Thanks.
>
> -Adam
Re: Dynamic 32-64 bit loading [message #825376 is a reply to message #824881] Tue, 20 March 2012 19:30 Go to previous messageGo to next message
Adam Fisk is currently offline Adam FiskFriend
Messages: 4
Registered: February 2012
Junior Member
Thanks Tom. I'm actually not too worried about byte code issues themselves but more with whether there are differences in the actual Java code, although those changes could include conversions for some stuff on the Java side before jumping across the native divide.

After a little more investigation, my current approach is somewhat similar to your suggestion but with swapping the dlls/jnilibs/so files depending on architecture -- stripping all native libs from the jars, shipping with all native libs but a single jar, and putting the appropriate jars on the java.library.path. The error with the stripped jar (no native libs available) at least makes the native lib search path clear to enable that strategy:

Uncaught exception: Could not load SWT library. Reasons:
no swt-cocoa-3738 in java.library.path
no swt-cocoa in java.library.path
Can't load library: /Users/afisk/.swt/lib/macosx/x86_64/libswt-cocoa-3738.jnilib
Can't load library: /Users/afisk/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib

So theoretically swapping the appropriate native libs into those locations should work. Risky in terms of the widening and narrowing conversions, as you say, but probably worth a shot.

Thanks again Tom.

-Adam


Re: Dynamic 32-64 bit loading [message #825718 is a reply to message #825376] Wed, 21 March 2012 07:00 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 5468
Registered: July 2009
Senior Member
For win32 x86 and x86_64 the java code beside the mentionned int/long
stuff is the same but the javacode between e.g. os-x and win is
completely different.

You need to swap the complete swt.jar!

Tom

Am 20.03.12 20:30, schrieb Adam Fisk:
> Thanks Tom. I'm actually not too worried about byte code issues
> themselves but more with whether there are differences in the actual
> Java code, although those changes could include conversions for some
> stuff on the Java side before jumping across the native divide.
>
> After a little more investigation, my current approach is somewhat
> similar to your suggestion but with swapping the dlls/jnilibs/so files
> depending on architecture -- stripping all native libs from the jars,
> shipping with all native libs but a single jar, and putting the
> appropriate jars on the java.library.path. The error with the stripped
> jar (no native libs available) at least makes the native lib search path
> clear to enable that strategy:
>
> Uncaught exception: Could not load SWT library. Reasons: no
> swt-cocoa-3738 in java.library.path
> no swt-cocoa in java.library.path
> Can't load library:
> /Users/afisk/.swt/lib/macosx/x86_64/libswt-cocoa-3738.jnilib
> Can't load library:
> /Users/afisk/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib
>
> So theoretically swapping the appropriate native libs into those
> locations should work. Risky in terms of the widening and narrowing
> conversions, as you say, but probably worth a shot.
>
> Thanks again Tom.
>
> -Adam
>
>
>
Re: Dynamic 32-64 bit loading [message #840927 is a reply to message #824633] Tue, 10 April 2012 17:29 Go to previous message
Andi Thomas is currently offline Andi ThomasFriend
Messages: 38
Registered: July 2009
Member
See:

http://stackoverflow.com/questions/2706222/create-cross-platform-java-swt-application/5784073#5784073

I've done something similar. I have an Ant build script that packages
all the SWT jars into a single jar along with the application code - in
a folder structure much as Tom suggests.

The main method for the app then creates a URL class loader with an
appropriate URL to load the correct SWT jar for the platform its running on.

You bulk up the size of your jar, but you then know you have a universal
runnable jar.

Right now I only package for Win32 & Win64 as that's my customer base.
Its simple enough to add Mac, Linux, etc.


On 3/19/12 6:22 PM, Adam Fisk wrote:
> I'd like to be create an SWT jar, let's say for Windows to keep it
> simple, that would dynamically load the 32 bit native SWT dlls if the
> JVM is 32 bit and the 64 bit SWT dlls if the JVM is 64 bit.
>
> It seems like someone must have done this before, but it's not clear to
> me how without patching SWT and doing it the hard way.
>
> Any advice would be much appreciated. Thanks!
>
> -Adam
Previous Topic:Table ScrollBar missing in GridLayout and Rowlayout
Next Topic:sigsegv linux-gtk with e4.2M6
Goto Forum:
  


Current Time: Thu Nov 27 09:53:38 GMT 2014

Powered by FUDForum. Page generated in 0.13700 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software