What's the recommended/official solution to this? Always use a 32-bit JVM with Fan? Manually install 64-bit SWT? Ideally Fan should ship with both 32- and 64-bit or provide two distinct download versions no?
andyFri 11 Sep 2009
With Snow Leopard defaulting to 64-bit VM on supporting hardware, I think we will have to package both versions into the main distro. I think ease of use should trump a few megs in this case.
cheeserFri 11 Sep 2009
Yeah, i just ran into this, actually. Last time I tried to build FWT with the 64 bit .so's it didn't turn out too well. Maybe i'll try again if i get some time soon...
brianFri 11 Sep 2009
this has come a couple times before
I am happy to put 64-bit versions of the SWT into the distro - for now I'd rather keep things to one big distro for all platforms.
However, since I can't test I need a bit of help. If someone gets it working, and just lets me know what files they used, I will add them. Although we might need some switch in the BASH scripts beyond uname to figure out what native library path to use. Someone (maybe tcolar) suggested manually loading the library with an absolute path to avoid that nastiness (haven't tried it yet).
brianMon 14 Sep 2009
Promoted to ticket #740 and assigned to brian
One thing I will definitely take a look at is to manage loading SWT native libs from Java code versus trying to set java.library.path in launcher C/bash code. That should make it easier to plug in new natives.
tcolarFri 6 Nov 2009
Any instructions on resolving this manually, until this ticket gets resolved ?
In other word where to get the 64 bits libraries and where to put them to make Fan happy.
Every time I try to do some Fan I run into this and it's just annoying.
Then extract the jar files into FAN_HOME/lib/java/ext/linux or FAN_HOME/lib/java/ext/mac
And then it works.
casperbangSat 7 Nov 2009
Glad you found a workaround tcolar. I admit to simply booting up a 32bit virtual image when I wanted to play with FWT!
brianSat 7 Nov 2009
This is next up on my todo list. I'm hoping to do a full build here in the next week or two (its been over a month since the last one)
brianTue 10 Nov 2009
Let me ask everyone out there - is there anyone who cares about 32-bit OS X? I think all the newer versions of OS X and the JVM are strictly 64-bit, so at this point 32-bit OS X support for SWT is sort of a legacy issue.
ivanWed 11 Nov 2009
I agree, 32-bit OS X SWT is just a history
freddy33Wed 11 Nov 2009
Especially since Java 1.6 (the needed base for Fan) exists only as 64 bits on Mac OS X, SWT 32-bit is kind of "useless" :)
brianSat 14 Nov 2009
Ticket resolved in 1.0.47
OK, I've reworked how Java extensions get loaded.
In the old model the launcher code tried to figure out what platform you were running and then explicitly added a platform specific directory to your classpath. The problem was we didn't have a formal set of platform identifiers, and figuring out platforms in a bash script was sort of arbitrary.
The new model is much cleaner. Platform identifiers are formalized to match Eclipse via the new Sys os, arch, and platform methods - see #756. You can see what your platform identifier is running fan -version:
Instead of having the launcher explicitly configure the classpath, the FanClassLoader is now a URLClassLoader and adds the appropriate extension directories automatically. These extension directories are:
{fan.home}/lib/java/ext/
{fan.home}/lib/java/ext/{Sys.platform}/
If anybody was relying on the system classloader path being set, this might be a breaking change for you.
As part of this redesign, I've upgraded the SWT jars from 3.4 to 3.5.1. Bundled in Fan are the following platforms:
win32-x86
macosx-x86_64
linux-x86
If your platform isn't supported, the process for getting SWT up and running is really easy now. Download your appropriate SWT jar from eclipse.org. Then drop the jar into lib/java/ext/{your-platform}.
It appears both Windows and OS X will extract the native code libraries from the jar automatically. So I am leaving the natives inside the jar file. I do not have access to a Linux box to test this behavior on Linux.
I would really appreciate a volunteer testing out hg tip on their Linux box before I do the next build.
tcolarSat 14 Nov 2009
Cool that should be cleaner.
Juts got a HG tip but failing to build it (linux 32 bits) ./buildall.fan full // OK ... until :
Does this tie back to the #670 discussion, allowing loading of extra jars from within the pod? Or is that a separate thing.
Idea being, if you want to distribute a pod that uses a special library, you should be able to include it in the pod and make the classloader look there for it. I don't know if that's possible now, seems like the discussion was we'd come back to it later.
brianSun 15 Nov 2009
Does this tie back to the #670 discussion, allowing loading of extra jars from within the pod? Or is that a separate thing.
Eventually it might tie back. I think as a first step, this change lays a solid foundation for identifying platforms and formalizing the existing extension design.
tcolarMon 16 Nov 2009
Tested that it works fine on linux 32 bits and linux 64 bits(64 bits needs the swt.jar added manually in lib/java/ext/linux-x86_64) since it's not included in the repo.
brianMon 16 Nov 2009
Thanks for tcolar for checking this out!
So right now I am distributing:
win32-x86
macosx-x86_64
linux-x86
Each SWT jar is about a 1.5 MB - so not huge, but not trivial to add to distro either.
I think the next ones we should consider are:
win32-x86_64
linux-x86_64
Once there is a clamouring for more 64-bit built-in SWT support we can add that. Although with new design it is pretty trivial to add SWT support for your own platform.
tcolarMon 16 Nov 2009
Agreed it can wait, would be nice to clearly let the user know (setup doc?).
I know there where some conversation of getting stuff from the repos/cloud, part of the bigger repo picture as mentioned here by Kevin n #670.
So maybe long term it would be cool if fan could fetch stuff like that online (kinda like maven) ... would keep the distro lightweight and be a cool feature for distributing fan based apps.
katoxSat 27 Mar 2010
I'd advocate adding at least linux-x86_64 -- just about every our linux server is running 64-bit OS + 64bit JVM.
It could potentially discourage some people not having 64-bit version working out-of-the-box when there is only a single download...
brianSun 28 Mar 2010
Well I think 64-bit windows would probably be a lot more valuable, and I don't want to throw everything in there because these files are huge.
I would suggest we pick one linux - either 32-bit or 64-bit whatever the community thinks is more useful
katoxSun 28 Mar 2010
Hard to say, most desktops use 32-bit (flash support etc) and most servers use 64-bit.
If there is a demand for 64-bit windows version already two separate downloads (all 32-bit and all 64-bit) would be probably the best option. HG could contain everything most people won't touch it anyway and the lib itself almost never changes.
tcolarMon 29 Mar 2010
I'm also a 64 bits desktop user, but most desktops are still 32 bits like katox said. Most (if not all) servers are 64 bits.
I don't think you have to put them all in the distro, but it would be nice if the other libs where easily available from the fantom site. Or maybe the launcher could just ask you "I need swt-x86-64(or whatever), do you want me to fetch it now ?", it gets it from the web and done. That would be pretty cool :)
tacticsMon 29 Mar 2010
I dunno about adding anything to the launcher. It's a one-time install, and it belongs in an installer program. (Something we don't have at the moment).
The MySQL driver should also be considered when it comes to external jar dependencies. We don't provide that one -- you have to go hunt it down yourself.
katoxSun 18 Jul 2010
Eclipse download links for SWT 64bit have changed. There is an updated version available at
casperbang Fri 11 Sep 2009
What's the recommended/official solution to this? Always use a 32-bit JVM with Fan? Manually install 64-bit SWT? Ideally Fan should ship with both 32- and 64-bit or provide two distinct download versions no?
andy Fri 11 Sep 2009
With Snow Leopard defaulting to 64-bit VM on supporting hardware, I think we will have to package both versions into the main distro. I think ease of use should trump a few megs in this case.
cheeser Fri 11 Sep 2009
Yeah, i just ran into this, actually. Last time I tried to build FWT with the 64 bit .so's it didn't turn out too well. Maybe i'll try again if i get some time soon...
brian Fri 11 Sep 2009
this has come a couple times before
I am happy to put 64-bit versions of the SWT into the distro - for now I'd rather keep things to one big distro for all platforms.
However, since I can't test I need a bit of help. If someone gets it working, and just lets me know what files they used, I will add them. Although we might need some switch in the BASH scripts beyond uname to figure out what native library path to use. Someone (maybe tcolar) suggested manually loading the library with an absolute path to avoid that nastiness (haven't tried it yet).
brian Mon 14 Sep 2009
Promoted to ticket #740 and assigned to brian
One thing I will definitely take a look at is to manage loading SWT native libs from Java code versus trying to set java.library.path in launcher C/bash code. That should make it easier to plug in new natives.
tcolar Fri 6 Nov 2009
Any instructions on resolving this manually, until this ticket gets resolved ?
In other word where to get the 64 bits libraries and where to put them to make Fan happy.
Every time I try to do some Fan I run into this and it's just annoying.
tcolar Fri 6 Nov 2009
Never-mind figured it out.
Download SWT zip for your platform here: http://download.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/index.php#swt
Then extract the jar files into FAN_HOME/lib/java/ext/linux or FAN_HOME/lib/java/ext/mac
And then it works.
casperbang Sat 7 Nov 2009
Glad you found a workaround tcolar. I admit to simply booting up a 32bit virtual image when I wanted to play with FWT!
brian Sat 7 Nov 2009
This is next up on my todo list. I'm hoping to do a full build here in the next week or two (its been over a month since the last one)
brian Tue 10 Nov 2009
Let me ask everyone out there - is there anyone who cares about 32-bit OS X? I think all the newer versions of OS X and the JVM are strictly 64-bit, so at this point 32-bit OS X support for SWT is sort of a legacy issue.
ivan Wed 11 Nov 2009
I agree, 32-bit OS X SWT is just a history
freddy33 Wed 11 Nov 2009
Especially since Java 1.6 (the needed base for Fan) exists only as 64 bits on Mac OS X, SWT 32-bit is kind of "useless" :)
brian Sat 14 Nov 2009
Ticket resolved in 1.0.47
OK, I've reworked how Java extensions get loaded.
In the old model the launcher code tried to figure out what platform you were running and then explicitly added a platform specific directory to your classpath. The problem was we didn't have a formal set of platform identifiers, and figuring out platforms in a bash script was sort of arbitrary.
The new model is much cleaner. Platform identifiers are formalized to match Eclipse via the new Sys os, arch, and platform methods - see #756. You can see what your platform identifier is running fan -version:
Instead of having the launcher explicitly configure the classpath, the FanClassLoader is now a URLClassLoader and adds the appropriate extension directories automatically. These extension directories are:
{fan.home}/lib/java/ext/{fan.home}/lib/java/ext/{Sys.platform}/If anybody was relying on the system classloader path being set, this might be a breaking change for you.
As part of this redesign, I've upgraded the SWT jars from 3.4 to 3.5.1. Bundled in Fan are the following platforms:
If your platform isn't supported, the process for getting SWT up and running is really easy now. Download your appropriate SWT jar from eclipse.org. Then drop the jar into
lib/java/ext/{your-platform}.It appears both Windows and OS X will extract the native code libraries from the jar automatically. So I am leaving the natives inside the jar file. I do not have access to a Linux box to test this behavior on Linux.
I would really appreciate a volunteer testing out hg tip on their Linux box before I do the next build.
tcolar Sat 14 Nov 2009
Cool that should be cleaner.
Juts got a HG tip but failing to build it (linux 32 bits)
./buildall.fan full// OK ... until :compile [fwt] Compile [fwt] FindSourceFiles [41 files] WritePod [file:/home/tcolar/fan2/fan-1.0/lib/fan/fwt.pod] javaNative [fwt] CreateDir [/home/tcolar/fan/src/fwt/temp-java/] Exec [/usr/lib/jvm/java-6-sun/bin/java -cp /home/tcolar/fan2/fan-1.0/lib/java/sys.jar fanx.tools.Jstub -d /home/tcolar/fan/src/fwt/temp-java fwt] Java Stub [fwt] CompileJava /home/tcolar/fan/src/fwt/java/PanePeer.java:12: package org.eclipse.swt does not exist import org.eclipse.swt.*; ^tcolar Sat 14 Nov 2009
Nevermind.
KevinKelley Sat 14 Nov 2009
Does this tie back to the #670 discussion, allowing loading of extra jars from within the pod? Or is that a separate thing.
Idea being, if you want to distribute a pod that uses a special library, you should be able to include it in the pod and make the classloader look there for it. I don't know if that's possible now, seems like the discussion was we'd come back to it later.
brian Sun 15 Nov 2009
Eventually it might tie back. I think as a first step, this change lays a solid foundation for identifying platforms and formalizing the existing extension design.
tcolar Mon 16 Nov 2009
Tested that it works fine on linux 32 bits and linux 64 bits(64 bits needs the swt.jar added manually in lib/java/ext/linux-x86_64) since it's not included in the repo.
brian Mon 16 Nov 2009
Thanks for tcolar for checking this out!
So right now I am distributing:
Each SWT jar is about a 1.5 MB - so not huge, but not trivial to add to distro either.
I think the next ones we should consider are:
Once there is a clamouring for more 64-bit built-in SWT support we can add that. Although with new design it is pretty trivial to add SWT support for your own platform.
tcolar Mon 16 Nov 2009
Agreed it can wait, would be nice to clearly let the user know (setup doc?).
I know there where some conversation of getting stuff from the repos/cloud, part of the bigger repo picture as mentioned here by Kevin n #670.
So maybe long term it would be cool if fan could fetch stuff like that online (kinda like maven) ... would keep the distro lightweight and be a cool feature for distributing fan based apps.
katox Sat 27 Mar 2010
I'd advocate adding at least
linux-x86_64-- just about every our linux server is running 64-bit OS + 64bit JVM.It could potentially discourage some people not having 64-bit version working out-of-the-box when there is only a single download...
brian Sun 28 Mar 2010
Well I think 64-bit windows would probably be a lot more valuable, and I don't want to throw everything in there because these files are huge.
I would suggest we pick one linux - either 32-bit or 64-bit whatever the community thinks is more useful
katox Sun 28 Mar 2010
Hard to say, most desktops use 32-bit (flash support etc) and most servers use 64-bit.
If there is a demand for 64-bit windows version already two separate downloads (all 32-bit and all 64-bit) would be probably the best option. HG could contain everything most people won't touch it anyway and the lib itself almost never changes.
tcolar Mon 29 Mar 2010
I'm also a 64 bits desktop user, but most desktops are still 32 bits like katox said. Most (if not all) servers are 64 bits.
I don't think you have to put them all in the distro, but it would be nice if the other libs where easily available from the fantom site. Or maybe the launcher could just ask you "I need
swt-x86-64(or whatever), do you want me to fetch it now ?", it gets it from the web and done. That would be pretty cool :)tactics Mon 29 Mar 2010
I dunno about adding anything to the launcher. It's a one-time install, and it belongs in an installer program. (Something we don't have at the moment).
The MySQL driver should also be considered when it comes to external jar dependencies. We don't provide that one -- you have to go hunt it down yourself.
katox Sun 18 Jul 2010
Eclipse download links for SWT 64bit have changed. There is an updated version available at
It is still sufficient to place
swt.jarinto$FAN_HOME/lib/java/ext/linux-x86_64respectively$FAN_HOME/lib/java/ext/win32-x86_64subdirectories.