Hi!
Last week I've found the project SWTSwing at
http://swtswing.sourceforge.net/.
The goal of this project is to implement the SWT GUI-Framework using standard Swing components.
First I will lay things out for you and then I'll post a message from Christopher Deckers the main person behind SWTSwing. Before I talked to Christopher I got in contact with Dieter Krachtus who is working together with Christopher on the Eclipse on Swing project (EoS;
http://eos.sourceforge.net/).
I got an older SWTSwing version from him, so I could execute the Paint example (see EoS website) on eComStation. After I got that working I began to spent some time with the Azureus code and created my own Azureus build. Together with the help of Retroweaver, which adds some functionality that has been missing in Java 1.4 but is available in Java 1.5 and Dieter's SWTSwing version I was able to start Azureus on eComStation. I even got to the main window (at the first tests it did stop at the end of the splash screen).
Here is a picture of Azureus running on eCS 2.0rc1 (I did post this 3 days ago at OS2.org - german discussion forum):

You can get the full sized version here:
http://www.juergen-ulbts.de/Sonstiges/Java/AzureusSWTSwing/Azureus2504_on_eCS20_using_older_SWTSwing-Lib.jpgThe application itself is not usable (see error messages in the background 4OS2 command line window)
So we are now back on the SWTSwing topic
Why is this project so important for us?- SWT is used for two applications everyone know...Azureus (Bittorrent Client) and of course Eclipse (Integrated development IDE for Java, C,...).
- SWT has to be ported to every target platform (for example eComStation and OS/2)!
- We currently don't have a working SWT port on eComStation and OS/2!
Ok, we don't have a working SWT port but there is work in progress. The push the project became last year did came to a stop around December 2006 and seems to be re-actived since about 5 weeks. Before we see a working SWT port there is still a lot work that needs to be done if it will be finished ever.
If you look at the wxWidget developers that are working for years now and what problems they still have you might get an idea how hard it is with very limited resources to get it working. Currently the wxWidget guys have problems with GCC 3.3.5 and also Open Watcom. Open Watcom doesn't support the required C functionality and it's the same with GCC. wxWidget is using more and more Unicode which is also causing problems. The other GUI Framework is Qt, we have a working Qt port, but it's also outdated (current eCS and OS/2 version is 3.3.1 and it's not a complete port -
http://svn.netlabs.org/qt3; Trolltech is currently using version 4.3.0 -
http://trolltech.com/developer/downloads/qt/windows).
I can't blame any developer working on the stuff above. They are working on it in their free time and they don't get paid for it...ok the qt3 development may be supported a little bit by netlabs.org. Maybe Adrian might tell us something if we ask.
SWTSwing seems to be very far in it's development as you can see when you look at the screenshots on the website. SWTSwing uses standard Swing that is part of Java since version 1.2 (was an additional package in Java 1.1.8 but maybe only because of IBM)
I don't know how many people beside Christopher and Dieter are working on SWTSwing, but what they did create so far is incredible!
Great so we can use SWTSwing to get applications running that require SWT?No that's unfortunatley not possible because of two reasons:
- SWTSwing is currently not Java 1.4 compatible, and we don't have access to newer versions of Java on eCS and OS/2
- The application that's using SWT also has to be compatible with Java 1.4 as well
It may be possible to get them involved to add Java 1.4 compatible checks but we may need some developers that could work on this project. Even some users testing it would be
VERY HELPFUL.
Another motivation might me our Bounty system!
I hope you all hear me.

I asked Christoper a few questions and this is what he said...
Hi Juergen,
Well, I knew this compatibility discussion was to come up some day.
Maybe discussing it further may help me find a solution.
A bit of background first. SWTSwing is quite a challenging project:
SWT is a moving target, and has a lot of advanced native-like
features. It brings competition to Swing, so Swing usually tries to
follow whatever SWT has, but of course with the delay implied by
waiting for a new JRE. This is why, to achieve a most complete
coverage of the SWT API, I need the latest official JRE. To give a few
examples:
- Absolute mouse location at any time (java 5)
- System tray support (java 6)
- Irregular shaped windows (planned for Java 7, I am waiting for it)
Compatibility concerns two aspects: using new constructs (generics,
enums) that imply a certain bytecode version, and the use of methods
from certain JREs.
Keeping track of compatibility is a really hard task. I did that
several times in the past and I know the various issues around it.
This is why I originaly decided that SWTSwing's goal would be to cover
a maximum of SWT, rather than supporting legacy JREs. On the other
hand, I knew there would be a need for these legacy JREs, so I set the
binary compatibility to Java 1.4, and never use 5.0+ constructs. This
allows an easer backporting of SWTSwing to earlier JRE versions by
external parties.
> After that I also tried to get Azureus working using the SWTSwing version from
> the Paint.jar. I recompiled Azureus for Java 1.5 and used Retroweaver to patch
> the bytecode to make it mostly Java 1.4 compatible.
I thought Retroweaver would just downgrade new Java 5 constructs to
Java 1.4. Since I use Java 1.4 compatibility, where does Retroweaver
help?
> Dieter told me that the old compatibility with Java 1.5 has been removed from
> the current SWTSwing code.
It is not that it was removed, it is just that I could finally
implement more of SWT using Java 6, and get big applications like
Eclipse to work better.
> Is there any chance to get Java 1.4 compatibility back into SWTSwing.
Well, I have to do a bit of downgrades for Java 5 compatibility at
least. That means, as long as you don't use certain SWT calls that
definitely require a Java 6 API, the program would not break. Now,
what would happen if you launch a program that does call such API
(like Azureus using the system tray)? There are two approaches: let
the program break, which means SWTSwing would be useful for programs
making the checks themselves, or handle those cases to return default
values. The latter requires compatibility checks in the code itself,
or special downgraded releases of SWTSwing.
> Dieter is
> currently thinking about this and maybe he has already an idea.
> I would say a parameter like "-Dswt.swing.java=1.4" but maybe it's sometimes
> easier to at a try..catch around Java method calls to catch
> "java.lang.NoSuchMethodError" and execute a Java 1.4 compatible call if
> available (for example usefull for the "setLocationByPlatform()" method call -
> only used in two *.java files right now).
The version you have may be enough for a paint application, but can't
run Eclipse properly. I put a lot of work in what's currently in CVS,
and there are probably far more calls that require a later JRE.
> Having SWTSwing working on eComStation would be appreciated by a lot of people
> as we don't have a native SWT implementation (even if the work on a port has
> been restarted recently).
> Currently we can't use a great applications like Eclipse, Azureus and other
> popular Java applications. A Java 1.4 compatible version SWTSwing would be very
> helpfull to make those applications work.
Now we touch the important aspect of this issue: to know if
compatibility handling is worth the trouble. I would love to learn
more about who still use OS/2, or Java 1.4, and evaluate if I should
spend some time on this support or let that to external parties.
I originaly mentioned to Dieter having AOP using external pointcut
definitions in order to avoid damaging the code with compatibility
checks, but I know it would not solve all the cases.
If you can give me more insight as to where such compatilibity would
be useful, and if you are willing to help testing a few dev versions
in case I implement anything, then I may handle it in the code itself.
In the meantime I will think about it to try to find a clean solution
in case I decide to go for it.
Cheers,
-Christopher