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?

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.

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...

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).

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.

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.

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.

Glad you found a workaround tcolar. I admit to simply booting up a 32bit virtual image when I wanted to play with FWT!

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)

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.

I agree, 32-bit OS X SWT is just a history

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" :)

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:

C:\dev\fan\src>fan -version
  ...
  java.home:       C:\Program Files\Java\jre6
  fan.platform:    win32-x86
  fan.version:     1.0.46

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.

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.*;
^

Nevermind.

OK, I've reworked how Java extensions get loaded.

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.

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.

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.

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.

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.

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...

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

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.

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 :)

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.

Eclipse download links for SWT 64bit have changed. There is an updated version available at

1. Linux x86_64 - http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.6-201006080911/swt-3.6-gtk-linux-x86_64.zip
2. Windows x86_64 - http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.6-201006080911/swt-3.6-win32-win32-x86_64.zip

It is still sufficient to place swt.jar into $FAN_HOME/lib/java/ext/linux-x86_64 respectively $FAN_HOME/lib/java/ext/win32-x86_64 subdirectories.