Moving an existing application to a new platform can be a huge undertaking, often requiring re-writing large portions of the code base to work in the new framework. However, moving a legacy AWT/Swing application to the Eclipse platform does not mean having to abandon the existing GUIs to take advantage of what Eclipse has to offer.
Take Diamond Light Source’s GUI for Data Acquisition (GDA) as an example.
Diamond’s GDA application was originally developed as a monolithic application using Swing for rendering GUIs. As the number of users and developers grew, Diamond decided that Eclipse could quickly provide new features, scalability and improved component interoperability. However, there was a problem with transitioning to a new platform: a large investment had already been made in Swing.
The Eclipse developers had already solved this problem though. They created an SWT_AWT bridge that allows a Swing/AWT component to be added as a component to an SWT composite. This bridge significantly simplified how Diamond was able to transition, by reusing existing Swing components, but still taking advantage of the new capabilities that Eclipse/SWT has to offer. A prime example of a feature that Diamond GDA users and developers desired was more control over the layout of the GUI. By embedding the existing Swing components into individual Eclipse views in a short period of time all the previously mostly static components were draggable, dockable and closeable.
The SWT_AWT bridge lowered the barriers that Diamond had to transitioning GDA to the Eclipse platform. Instead of having to re-write all the necessary component in the new framework, Diamond developers were able to take advantage of Eclipse very quickly and roll out those improvements to the users in record time.
For the technical details on how to use the bridge, see the excellent article by Gordon Hirsch http://www.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html. Unfortunately, integrating the SWT_AWT bridge has suffered from some headaches when using Xlib (as used on Linux/GTK systems). Some of the Xlib APIs are inherently not thread safe in their design. For example, XSetErrorHandler, which returns the old error handler when setting a new one. Without some application level locking, it is easy to get the error handler into a state when the currently installed error handler is incorrect. When using the SWT_AWT bridge, two separate threads are both accessing Xlib APIs. This can cause the AWT thread to have a stack overflow. The underlying problem will remain due to the Xlib APIs, however, SWT and AWT can avoid using XSetErrorHandler, and therefore avoid this issue. These issues are discussed more fully in Eclipse Bug 171432. The AWT issue has already been fixed in JDK7 build 60, but the fix has not yet been back ported to JDK 6. See Bug and Revision with fix.
Kichwa Coders 