Eclipse Community Forums: Standard Widget Toolkit (SWT)

Help

Home

Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Dynamic 32-64 bit loading

Show: Today's Messages :: Show Polls :: Message Navigator

Dynamic 32-64 bit loading [message #824633]

Mon, 19 March 2012 22:22

Adam Fisk

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

Report message to a moderator

Re: Dynamic 32-64 bit loading [message #824673 is a reply to message #824633]

Mon, 19 March 2012 23:25

Adam Fisk

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

Report message to a moderator

Re: Dynamic 32-64 bit loading [message #824881 is a reply to message #824673]

Tue, 20 March 2012 07:23

Thomas Schindl

Messages: 6568
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

Report message to a moderator

Re: Dynamic 32-64 bit loading [message #825376 is a reply to message #824881]

Tue, 20 March 2012 19:30

Adam Fisk

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

Report message to a moderator

Re: Dynamic 32-64 bit loading [message #825718 is a reply to message #825376]

Wed, 21 March 2012 07:00

Thomas Schindl

Messages: 6568
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
>
>
>

Report message to a moderator

Re: Dynamic 32-64 bit loading [message #840927 is a reply to message #824633]

Tue, 10 April 2012 17:29

Andi Thomas

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

Report message to a moderator

Previous Topic:	Table ScrollBar missing in GridLayout and Rowlayout
Next Topic:	sigsegv linux-gtk with e4.2M6

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Sep 30 10:40:08 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter