| |||||||||||||
|
| |||||||||||||
Swing and AWT, arghSwing and AWT, arghPosted May 19, 2006 23:18 UTC (Fri) by man_ls (subscriber, #15091)Parent article: Harmony project to get a Swing/AWT implementation Sun controls the Java specification. This means that they can say what is Java and what not; this power came in handy to stop Microsoft from subverting the language (and earn a lot of money in the process). But, as the linked post says, the spec contains the brain-dead AWT and the doubly brain-dead Swing. Let me rant a little. Many Java libraries should have been optional; having Swing support on a machine without X Window is not very useful. But no, everything went into the spec and everything had to be there. This is not about Microsoft adding its own classes into the mix, but about people removing what they don't need. Sun wanted to have everything there, always, so developers could depend on the features at runtime. But this is hardly useful most of the time; having java.sql on a machine without an installed database is not going to help. The Abstract Windowing Toolkit or AWT was an attempt to make a graphical environment that could be used on any system. Sadly, it was very limited in scope; in its day multi-platform graphical toolkits were still beginning to take shape. (Remember when it was cool to run an "applet" within your browser?) Very soon Sun wanted to add new functionality, but the need to maintain backwards compatibility made it difficult. Around 1999 and the misleadingly called Java 2 (officially it was 1.2), Sun engineers came up with an utterly stupid solution which solved a problem that nobody had. The all-Java (or pure Java in Sun parlance) graphical toolkit was built on top of AWT: with it the interface could sport a Windows look-and-feel on Solaris and viceversa. Very useful. In the process they created a slow, highly bloated environment and a memory hog, which needed endless optimizations to be barely useful. By the way, all look-and-feels were ugly. This monstrosity was called Swing. So now we are stuck with it forever. In fact, gcj and GNU Classpath are mostly complete except for AWT and Swing. Meanwhile, IBM (and later the Eclipse project) found the time to build a much lighter and faster environment, called Standard Widget Toolkit or SWT. It uses the novel (yeah, right) idea of using platform-specific code internally to display controls, and still presenting a uniform API. It's good stuff. The bad news is: even if you only want to use SWT applications, you still have to carry the burden of Swing. This latest addition to Harmony must therefore be useful to some people. I cannot figure out why did Intel have a Swing/AWT implementation to donate, but I guess we will find out soon.
(Log in to post comments)
Swing and AWT, argh Posted May 22, 2006 14:50 UTC (Mon) by lauwenmark (guest, #37754) [Link] Sun engineers came up with an utterly stupid solution which solved a problem that nobody had. The all-Java (or pure Java in Sun parlance) graphical toolkit was built on top of AWT: with it the interface could sport a Windows look-and-feel on Solaris and viceversa. Very useful.The problem it solved was that the way AWT behaved and looked like changed a lot between its various implementations. The goal of using Swing was to provide an abstraction layer that made possible for an application to display and behave exactly the same on all platforms - a goal the limited design of AWT was unable to fullfill. Let's also not forget that Swing provides a MVC model which AWT lacked - that too was a rather important progress. In the process they created a slow, highly bloated environment and a memory hog, which needed endless optimizations to be barely useful. By the way, all look-and-feels were ugly. This monstrosity was called Swing. Given that the current implementations of Swing are able to use underlying accelerated graphical capabilities (D3D/OpenGL) where available, the lack of speed Swing had in the past seems hardly relevant nowadays. Now, maybe you have some benchmarks to back up your facts ? As for the Look-and-Feels, it is mostly a subjective point - and nothing prevents you to develop and use your own LnF if you don't like the provided ones. So now we are stuck with it forever. In fact, gcj and GNU Classpath are mostly complete except for AWT and Swing. AWT and Swing are large libraries with lots of classes to implement. And they weren't the most needed classes to implement first. Moreover, no compatibility test suite existed for Swing/AWT, so it is not easy to guess the correct behavior in all cases. Meanwhile, IBM (and later the Eclipse project) found the time to build a much lighter and faster environment, called Standard Widget Toolkit or SWT. It uses the novel (yeah, right) idea of using platform-specific code internally to display controls, and still presenting a uniform API. It's good stuff. The bad news is: even if you only want to use SWT applications, you still have to carry the burden of Swing. Other bad news related to SWT: only the Windows implementation is decent performance-wise; the documentation is far from the level of what's available on Swing; SWT programming requires manual ressource-management; portability is inferior, some features not being available on all supported platforms. Underlining the deficiencies of Swing is one thing - but next time, try not to forget to also underline those of SWT to compare both.
Swing and AWT, argh Posted May 22, 2006 17:13 UTC (Mon) by philips (guest, #937) [Link] > Underlining the deficiencies of Swing is one thing - but next time,> try not to forget to also underline those of SWT to compare both.
Well, I'm not sure what kind of platform you run, Swing examples run dog slow and unresponsive on my Linux box (AMD64 X2). Anything more complicated than simple text editor is unusable due to very high latencies. (*). GVIM with syntax highlighting open on busy remote server over X protocol tunneled over ssh runs snappier than localy run Swing demos from Java SDK.
On side note, SWT thou not perfect, quite usable - here I'm judging by Eclipse - on both Windows and Linux. I personally use vim - but most of my friends use solely Eclipse with plug for C/C++ as their primary development environment. (**)
Probably Swing is designed better than SWT. It doesn't matter to me much since I haven't seen single worthy Java GUI application using Swing. And I have on network bunch using SWT.
(*) Okay, I'm touchtypist and quite sensitive to such stuff. Probably others are okay with the delays and flickering.
(**) Just recalled. Azureus - BitTorrent Java client - uses SWT and runs on Windows, Linux & Macs. I used it on many occasions on all of the aforementioned platforms. In other words, SWT much more portable than parent tries to imply.
Swing and AWT, argh Posted May 22, 2006 22:20 UTC (Mon) by man_ls (subscriber, #15091) [Link] The goal of using Swing was to provide an abstraction layer that made possible for an application to display and behave exactly the same on all platforms - a goal the limited design of AWT was unable to fullfill.Yes, that is exactly what I was talking about: a problem that nobody had. People wanted their programs to look different on different operating systems, not uniformly ugly. That is why all the other toolkits (Qt, GTK, wxWidgets, the old OPENSTEP) look different on different targets. And still some people don't get it. Given that the current implementations of Swing are able to use underlying accelerated graphical capabilities (D3D/OpenGL) where available, the lack of speed Swing had in the past seems hardly relevant nowadays.Hardware acceleration does not magically solve all problems. In fact 3d hardware acceleration solves very specific problems; it does nothing for bloat. Now, maybe you have some benchmarks to back up your facts ?Not really, since the question is not that hot any more. Right now I can offer you some home benchmarks which you will not accept anyway (and with good reason).
[...] nothing prevents you to develop and use your own LnF if you don't like the provided ones.Let us see... Yes, boredom prevents me. SWT looks good (or as bad as the rest on my OS) without any efforts. Other bad news related to SWT: only the Windows implementation is decent performance-wise;Some years ago I tried eclipse on my old iMac DV, and it barely run at all (whereas other Swing programs just refused to even try). On my old Linux machine running Sun's JRE it worked, not very fast but usable.
Well, guess what: I just downloaded eclipse for my Ubuntu system, and it runs quite fine. Even though (or maybe because) it uses the documentation is far from the level of what's available on Swing;In my limited experience I don't have complains. SWT programming requires manual ressource-management; portability is inferior, some features not being available on all supported platforms.The rest of your concerns should be answered by people more knowledegeable than myself, like Chris Grindstaff. There are one other aspect of SWT which is probably of interest in this forum: SWT is free software. Swing is not, at least until this Harmony thing came along.
|
|
||||||||||||