In his editorial "Swing Is Swinging Java out of the Desktop" (JDJ, Vol. 7,
issue 10) Alan Williamson lamented the current state of Swing and AWT for
building competitive desktop applications. One alternative he mentioned is a
technology called SWT (Standard Widget Toolkit) that was developed as part
of the Eclipse Project (www.eclipse.org). If you're wondering why the
Eclipse community, led by IBM, developed SWT instead of using J2SE's AWT or
Swing classes, here's the reason.
Eclipse is an open, universal platform for building and integrating
development tools. The users of development tools are, typically, developers
and they are a demanding lot. So Eclipse had to be designed to deliver a
high-performance user experience and integrate well with native operating
systems. In the early development phase of the project, the Eclipse
developers found that AWT was too limited and Swing did not provide the
native integration and performance they needed. Not to say that either is
inherently good or bad, just that they didn't meet the requirements of this
particular Java application. And that's an important point - the Eclipse
platform is a Java application that runs on the J2SE platform.
As Alan pointed out in October, AWT does not provide a satisfying
solution for most desktop applications. But Sun provides additional
functions in the Swing classes to give Java developers the power of maximum
user interface customization and cross-operating system consistency. The
power of the Swing classes comes at a price, however, paid in abstraction
from the operating system platform and its effect on application
performance. In the case of Eclipse, it was not a priority to have an
identical user interface across different platforms, but rather to maximize
performance and integration and leverage each platform's capabilities. Thus
SWT was born.
Swing and SWT both provide a common programming API across multiple
operating systems, but that's where the similarity ends. Swing widgets are
rendered by Java code, using graphics calls to "paint themselves," while SWT
widgets use the operating system widgets directly via J2SE's JNI API. Since
SWT is designed to embrace native window systems rather than emulate them,
SWT applications have the exact look and feel of the host operating system.
This means, for example, that SWT applications pick up the new Windows XP
look without any code changes or delay while new emulation code is
developed. This design approach also allows an application to leverage
platform features such as drag-and-drop and event-merging optimizations. The
result is that SWT applications truly look and perform like native
applications.
SWT was developed because the Eclipse community needed a
high-performance widget toolkit that integrated fully with Windows and other
native toolkits such as GTK and Motif. But with the rapid and widespread
adoption of Eclipse technology, many developers have found that SWT also
answers an important need they have for high-performance native user
interfaces in their non-Eclipse-based applications.
SWT is available for anyone to use under a true open-source license, and
is developed and maintained by an open-source community. However, many Java
developers feel it is time for SWT to be submitted to the JCP to bring it
into the Java "fold," so to speak, as an additional user interface option.
IBM would likely support a JSR that incorporates SWT as a complement to the
AWT and Swing options - along the lines of how Java specifications
incorporate support for other open-industry technologies such as XML and
SOAP.
At the end of his editorial Alan says, "If you need your faith in Java
reenergized, look to the community and what they are doing." We couldn't
agree more.
About Bernie Spang Bernie Spang, director of WebSphere Studio Marketing, is a computer engineer who led the public launch of the Eclipse project in 2001.
About Dave Thomson Dave Thomson was one of the founding employees of Object Technology International (OTI), a company IBM acquired in 1996 and which has become the foundation for IBM's Ottawa Lab and many of the technologies underlying IBM's tool products. Prior to OTI's integration with IBM Dave served as VP Development at OTI. Dave led the teams that delivered the underlying IDE technology in many of IBM's award-winning products including: VisualAge for Smalltalk, VisualAge for Java, and the Eclipse platform. Dave was the principal architect behind the transition of IBM's internal workbench development effort into the open source project we now know as Eclipse. Dave is an IBM Distinguished Engineer and is responsible for IBM's Eclipse Development team, and serves as a director on the board of the Eclipse Foundation.
Reader Feedback: Page 1 of 2
#26
marco marcelo commented on 19 May 2003
#25
AW commented on 8 Apr 2003
Alex Prayle,
can you provide a code sample to demonstrate an "efficiently implemented TableModel" ?
This could have been possible with AWT/Swing apps too, if Sun JRE license was not too restricive...
#23
Travell Perkins commented on 1 Apr 2003
The dot com boom had to be the worst thing for client side development in general. Coding a proper client takes as much skill as any server side process. The problem is that most developers have not cultivated the proper skills for client side dev, focusing primarily on the server side and HTML clients. Further more few frameworks provide more than just a handful of widgets; Swing and SWT are both guilty of this. As far as Swing performance goes, its not a problem. I have implemented a next generation client side UI framework using IntelliJ as my dev environment and the framework is built on top of Swing. I use to code in Netbeans which is a complete dog. IntelliJ is blazing and guess what? They turn off directdraw for the Java2D subsystem by default! Note: The GDI in Windows XP is blazingly fast compared to previous implementations.
Bottom line. If a Java client side application is slow blame the developer or the hardware, but leave the widgets out of it because it ain't them. As far a JTables go when designing your table models think JDBC and scrollable result sets.
#22
Nick Evgeniev commented on 1 Apr 2003
Hi,
The first thing I have to mention SWT is not a true cross platform library. Trust me I program in both the Swing and SWT.
a) Each platform support requries to write huge amount of code. Just check the SWT source by yourself. While windows x86 implementation is more or less production quality, the other ports are vary from alpha stage (MacOS, PocketPC) to early beta(linux).
b) With every added platform SWT development becomes slower and slower because API was designed by Windows programming people who knows nothing about other platforms.
c) SWT was designed not as an Standard widget toolkit, but as Eclipse widget toolkit. So, if you are designing application that doesn't look (behaves) like eclipse then you are in trouble. Just check eclipse.tools forum or TRUST ME.
The problem of Swing is not the speed but low qualified developers. Just try to compare borland JDeveloper (dog slow) and IDEA that runs at reasonable speed.
#21
Mike commented on 14 Mar 2003
Some interesting open source alternative to AWT and Swing. Support nearly all java versions (starting from 1.1)
For those who believe that Swing is a great UI system, feel free to use it.
Personally, I am almost GRATEFUL that SWT has come along to provide me with a UI for my Windows-based Java apps. I have now built major apps with both Swing and SWT, and the SWT user experience wins, hands down. Swing tends to be slow and frustrating. SWT is almost universally snappy and responsive.
Not only that, but SWT allows me access to the wide world of ActiveX objects. In particular, I have been able to script MS Excel from within my Java app - a very useful feature for those who write business apps, since a lot of worthwhile corporate data is ferreted away in Excel workbooks.
SWT is the right choice, abstract enough and native as it can be, it must be promoted to standard.
In fact SWT can be described as AWT made without excessive haste.
When the Java developers had to create Swing, they must have thought that trying to use native toookits under a thin layrer of abstraction was too difficult.
Designing a new toookit from scratch with its rules and look and feel was more attractive and rewarding for the developers.
The look and feel of the platform could be easily emulated, they thought.
The outcome is that you have a java look wherever you go. Even with emulation you have two pitfalls. One: it is not perfect and you can tell it is not native (jgoodies can do something about that); two: seeing a Java application trying to have a Windows 2000 look and feel when you are running XP is funny (nice try, swing).
This is the original sin: putting all Java developers in a ghetto for the imposssible quest of the universal look and feel.
Further, the tipical Java application has a "Franken UI" because most defaults are not well chooosen.
Look carefully at www.jgoogies.org and it will be clear how far a little tweaking can take Swing.
Mozilla went the same way, but at least XUL makes things much easier, because any web developer that knows XML and JavaScript can change something in the interface.
If I had to use Swing (happily I don't), I would fix it with the jgoodies library, but if I had to develop something with a user interface I will take the SWT path.
All in all, Java on the desktop is just as appealing as Python with Tkinter: nice language horrible look.
Luckily there are servlets, where Java really shines and one can do the presentation in a number of ways.
Conga is Java's fastest and easiest way to create rich GUIs which are 100% Java.
Have looked at SWT and Swing, and am convinced that you can get a lot better mileage out with Conga.
#17
Anthony commented on 6 Mar 2003
Rather than unsubstantiated opinions, has anyone actually actually done some benchmarks? I'd love to hear about even one operation well implemented on SVG and Swing in which one was better than the other.
Also, if SVG really is better than Swing, is that because C++ in the O/S is faster than Java? That would be a serious criticism. Maybe adding things like C# Struts to Java would help...
#16
Chuck Jang commented on 5 Mar 2003
First, Eclipse doesn't promote anything- it's an open source community. Secondly, the reason there isn't a GUI Builder was for political reasons more than any other. IBM had to spare Sun the final embarrassment of releasing something that was conceptually superior to anything Sun ever released.
#15
Jon Perez commented on 5 Mar 2003
Considering that Swing performs nicely under Mac OS X(*), the problem seems to be that it is not Swing itself but its implementation on Win32 and Linux. Sun cares far less about Swing than Apple does it seems... pity. If it did then Swing and Java on the desktop (on the 3 major platforms - Mac, Windoze, Linux) would now probably be a lot more popular than it is right now.
I don't mind the non-native L&F as the whole point of Swing is to be _cross-platform_ standard.
(*) I don't know if its a memory hog under Mac OS though...
#14
Josh Knowles commented on 5 Mar 2003
All you have to do is look at products like IntelliJ to see that Swing can handle it, and it will only get better.
#13
Carlos Perez commented on 5 Mar 2003
The argument that Swing doesn't look like Windows or its native OS and therefore its a bad option is completely ludicrous.
Applications these days come in all sorts of look and feel. Just look at all those multimedia players. They don't look anything like Windows. Windows XP doesn't look like Windows, people are used to seeing different kinds of windows, and guess what, people don't mind!
#12
Carlos Perez commented on 5 Mar 2003
A fair comparison of Swing vs SWT is to look at IDEA. IDEA is at par with Eclipse's capabilities, but its written in Swing.
What the Java world needs to do, is to follow the lead of www.jgoodies.com , what that means is to make it easier to write Swing applications that look good. Swing is highly capable, the big question though is that if you're a novice, can you write something that looks nice?
I think this article is born out of pure ignorance, the fact that it comes from this magazine is embarrasing. Furthermore, the Eclipse project doesn't promote the use of SWT outside of the IDEA, if it did, you would have a gui builder for SWT. If you did benchmarks on the table class for SWT, you'll find it doesn't perform as well as Swing.
Dmitry Leskov wrote: ... that SWT in combination with one third-party tool enable GUI Java apps to be distributed as compact native Windows EXEs running without the JRE?
http://www.excelsior-usa.com/jetswt.html
This could have been possible with AWT/Swing apps too, if Sun JRE license was not too restricive...
Travell Perkins wrote: The dot com boom had to be the worst thing for client side development in general. Coding a proper client takes as much skill as any server side process. The problem is that most developers have not cultivated the proper skills for client side dev, focusing primarily on the server side and HTML clients. Further more few frameworks provide more than just a handful of widgets; Swing and SWT are both guilty of this. As far as Swing performance goes, its not a problem. I have implemented a next generation client side UI framework using IntelliJ as my dev environment and the framework is built on top of Swing. I use to code in Netbeans which is a complete dog. IntelliJ is blazing and guess what? They turn off directdraw for the Java2D subsystem by default! Note: The GDI in Windows XP is blazingly fast compared to previous implementations.
Bottom line. If a Java client side applicatio...
Nick Evgeniev wrote: Hi,
The first thing I have to mention SWT is not a true cross platform library. Trust me I program in both the Swing and SWT.
a) Each platform support requries to write huge amount of code. Just check the SWT source by yourself. While windows x86 implementation is more or less production quality, the other ports are vary from alpha stage (MacOS, PocketPC) to early beta(linux).
b) With every added platform SWT development becomes slower and slower because API was designed by Windows programming people who knows nothing about other platforms.
c) SWT was designed not as an Standard widget toolkit, but as Eclipse widget toolkit. So, if you are designing application that doesn't look (behaves) like eclipse then you are in trouble. Just check eclipse.tools forum or TRUST ME.
The problem of Swing is not the speed but low qualified developers. Just try to compare borland JDeveloper (dog...
Mike wrote: Some interesting open source alternative to AWT and Swing. Support nearly all java versions (starting from 1.1)
Check online demo (should work in most browsers including IE):
http://www.zaval.org/products/lwvcl/demo/index.html
Stephen Strenn wrote: For those who believe that Swing is a great UI system, feel free to use it.
Personally, I am almost GRATEFUL that SWT has come along to provide me with a UI for my Windows-based Java apps. I have now built major apps with both Swing and SWT, and the SWT user experience wins, hands down. Swing tends to be slow and frustrating. SWT is almost universally snappy and responsive.
Not only that, but SWT allows me access to the wide world of ActiveX objects. In particular, I have been able to script MS Excel from within my Java app - a very useful feature for those who write business apps, since a lot of worthwhile corporate data is ferreted away in Excel workbooks.
Michele Costabile wrote: SWT is the right choice, abstract enough and native as it can be, it must be promoted to standard.
In fact SWT can be described as AWT made without excessive haste.
When the Java developers had to create Swing, they must have thought that trying to use native toookits under a thin layrer of abstraction was too difficult.
Designing a new toookit from scratch with its rules and look and feel was more attractive and rewarding for the developers.
The look and feel of the platform could be easily emulated, they thought.
The outcome is that you have a java look wherever you go. Even with emulation you have two pitfalls. One: it is not perfect and you can tell it is not native (jgoodies can do something about that); two: seeing a Java application trying to have a Windows 2000 look and feel when you are running XP is funny (nice try, swing).
This is the original sin: putting all Java devel...
Lane Sharman wrote: Conga is Java's fastest and easiest way to create rich GUIs which are 100% Java.
Have looked at SWT and Swing, and am convinced that you can get a lot better mileage out with Conga.
Anthony wrote: Rather than unsubstantiated opinions, has anyone actually actually done some benchmarks? I'd love to hear about even one operation well implemented on SVG and Swing in which one was better than the other.
Also, if SVG really is better than Swing, is that because C++ in the O/S is faster than Java? That would be a serious criticism. Maybe adding things like C# Struts to Java would help...
Chuck Jang wrote: First, Eclipse doesn't promote anything- it's an open source community. Secondly, the reason there isn't a GUI Builder was for political reasons more than any other. IBM had to spare Sun the final embarrassment of releasing something that was conceptually superior to anything Sun ever released.
Jon Perez wrote: Considering that Swing performs nicely under Mac OS X(*), the problem seems to be that it is not Swing itself but its implementation on Win32 and Linux. Sun cares far less about Swing than Apple does it seems... pity. If it did then Swing and Java on the desktop (on the 3 major platforms - Mac, Windoze, Linux) would now probably be a lot more popular than it is right now.
I don't mind the non-native L&F as the whole point of Swing is to be _cross-platform_ standard.
(*) I don't know if its a memory hog under Mac OS though...
Carlos Perez wrote: The argument that Swing doesn't look like Windows or its native OS and therefore its a bad option is completely ludicrous.
Applications these days come in all sorts of look and feel. Just look at all those multimedia players. They don't look anything like Windows. Windows XP doesn't look like Windows, people are used to seeing different kinds of windows, and guess what, people don't mind!
Carlos Perez wrote: A fair comparison of Swing vs SWT is to look at IDEA. IDEA is at par with Eclipse's capabilities, but its written in Swing.
What the Java world needs to do, is to follow the lead of www.jgoodies.com , what that means is to make it easier to write Swing applications that look good. Swing is highly capable, the big question though is that if you're a novice, can you write something that looks nice?
I think this article is born out of pure ignorance, the fact that it comes from this magazine is embarrasing. Furthermore, the Eclipse project doesn't promote the use of SWT outside of the IDEA, if it did, you would have a gui builder for SWT. If you did benchmarks on the table class for SWT, you'll find it doesn't perform as well as Swing.
Brandon Rife wrote: Operating systems have a look and feel that users get used to and feel comfortable with. Deviating from that L&F is asking for trouble. I'm sick of jumping through hoops to make Swing apps look, feel, and behave like native OS applications. SWT is the right philosophy - When in Rome do as the Romans...or your app will end up in the catacombs.
Noble Paul wrote: At some point swing might end up somewhere close to native UI in speed and performance.But it still is a memory hogging beast. Just take a look at the amount of memory consumed by the leading java IDE Intellij and Eclipse. Moreover why should the user sacrifice the look and feel which he is used to in his favourite OS.
Most of the applications can do without custom Widgets. At least , that is what we should assume from the millions of web applications we see around.
I strongly believe SWT applications on Java web start can fill the gap for a true clientside low footprint applications platform. That will ultimately help java reign the desktop the way it did with the server.
Chuck Jang wrote: It amazes me that this debate is still alive. If it weren't for the relative immaturity of SWT, we wouldn't even be having this exchange. SWT is technically superior to Swing in every way that's important. If you've invested alot of time using Swing, that doesn't mean you should stay invested. The stock market thud seems like a good analogy.
gumby wrote: I fail to see the large-scale advantage of SWT. Extending even a simple widget (which is inevitable, except for uninteresting GUIs) is a PITA. If your sole target is windows, then why not just code in C#? And if it's not, do you really want to invest the extra cross-platform coding and testing time for SWT? Because in order to use native GUI components, you have to use the data models for those native components.
I do most development on OSX, so maybe I've just never seen this "huge" speed advantage (yes, I've tried eclipse on both w32 and OSX). And a speed advantage alone has never succeeded in supplanting solutions which in the end are easier to manage or develop (VB, anyone?)
M.Schipperheyn wrote: Just look at any Java IDE based on Swing, e.g. JDeveloper from Oracle. Great stuff, but SLOOOOOOWWWWWW. Then check out Eclipse. Even better than JDeveloper and very comparable. Great stuff and lightning fast. To realize that all these years we have been punished with Swing and AWT while we could have had SWT (or something similar) is mind boggling. Let's hope SWT becomes part of the standard.
CloudBench Applications, Inc. announced its financial results for the three months and nine months ending September 30, 2009. All amounts are stated in Canadian dollars unless otherwise noted. Revenues from BasicGov, the Company's cloud computing solution for local government, gr...
The new contract is an industry first, with CSC being the first Microsoft partner to lead and win a cloud computing services agreement of this scale. Under terms of the contract, CSC will provide Royal Mail Group's 30,000 employees with access to new IT services using Microsoft's...
Operates in over 170 countries and is one of the world’s leading providers of communications solutions and services. Richard Tarboton talks for MeettheBoss.TV on his role as Head of Energy & Carbon for BT and what they are doing towards reducing carbon emissions.
CA is going to put its Agile Planner software on salesforce.com’s Force.com platform in the first half to accelerate development time and give users visibility over their development initiatives to reduce time-to-market. Customers are supposed to be able to accelerate the deploym...
Despite its uncertain fate Sun soldiers on. Monday it trotted out a cloud-based multiplatform desktop as a service for K-12 and community colleges that can run Windows, the Mac OS, Linux and Solaris applications to nearly any client device, including its own Sun Ray thin clients....
About Newsfeeds / Video Feeds
.gif)
CloudBench Applications, Inc. announced its financial results for the three months and nine months ending September 30, 2009. All amounts are stated in Canadian dollars unless otherwise noted. Revenues from BasicGov, the Company's cloud computing solution for local government, gr...
The new contract is an industry first, with CSC being the first Microsoft partner to lead and win a cloud computing services agreement of this scale. Under terms of the contract, CSC will provide Royal Mail Group's 30,000 employees with access to new IT services using Microsoft's...
Operates in over 170 countries and is one of the world’s leading providers of communications solutions and services. Richard Tarboton talks for MeettheBoss.TV on his role as Head of Energy & Carbon for BT and what they are doing towards reducing carbon emissions.
CA is going to put its Agile Planner software on salesforce.com’s Force.com platform in the first half to accelerate development time and give users visibility over their development initiatives to reduce time-to-market. Customers are supposed to be able to accelerate the deploym...
Despite its uncertain fate Sun soldiers on. Monday it trotted out a cloud-based multiplatform desktop as a service for K-12 and community colleges that can run Windows, the Mac OS, Linux and Solaris applications to nearly any client device, including its own Sun Ray thin clients....
