Submitted On 10-MAR-2000
patn
I must completely disagree with the post about maintaining the life of AWT.
The single largest impediment to Java's adoption has been the lack of
portability attributable almost entirely to AWT. The much heralded (and
completely premature) "death of Java on the client side" was due to the fact
that Java came packaged with a large, non portable C application called AWT
that simply did not work. We must move on in the direction of pure Java
implementation as much as possible. Native look and feel can be reproduced in
a portable way or give way to more universal alternatives.
It is an interesting historical note that the original work by the Java
designers was towards a pure, light weight framework and it was only after
last minute pressure by Netscape for the initial release that they were forced
to compromise and produce the horrible AWT.
Pat Niemeyer
Author of Exploring Java, O'Reilly & Associates
Submitted On 10-MAR-2000
scaselli
I agree completely. Swing is really too slow
for me.
Submitted On 10-MAR-2000
gpaulus
I need AWT : it is much faster, more robust and also more suited for heavy-duty programs solving
real-world problems.
Submitted On 10-MAR-2000
fuzzey
no way.
Give me Swing any day. AWT falls down when you want more than a button. And where are all the MVC goodies?
In 1.3 Swing performance is fine on modern hardware.
Submitted On 14-MAR-2000
navneet
Look at this, why are there incompatibilities in the
various platform releases of Java. Mainly because of the
native protions of the JVM. AWT support is one of the main
components there. If we can do away with the native portion
of AWT in the JVM we may end up with better compliant JVMs
on the various platforms.
Continuing with AWT is a good idea if we can do AWT in a
lightweight manner. This could actually give us two GUI
libraries and let them compete on the feature and speed
front. We could define the priorities for either library as
speed and l&f/easy-of-use or any other criteria. This is
friendly competition and they could collaborate on this
too. The end result would be that the developer would win.
Submitted On 26-JUL-2000
steevcoc
P.S.
And hey, let's face it; we're only pissing our engineers off
by making them develop libraries which mimic a system's L&F -
and then making them track it to boot.
Peace,
Steev.
Submitted On 26-JUL-2000
steevcoc
I thought of another point I'd like to make about this. On
even a single platform like the Mac, there are a number of
alternative frameworks which do not use some or all native
controls. This has lead to a number of major applications
being stuck with ever-aging controls as the system evolves.
I see two interesting points in here. First, there are
already a number of "enhanced" Swing L&F libraries out there,
beginning potentially problematic derivatives. And second,
by not giving the developer at least the _option_ to access
true native controls from within the core Java API, we would
fail in preserving a tangible link to the native host.
I think the second point warrents a bit of consideration.
Peace,
Steev.
Submitted On 05-MAR-2001
peastman
I would *love* to see the additions mentioned above. My
company writes Java applications for analysis and
visualization of scientific data. We use exclusively AWT
and avoid Swing like the plague. Many people simply refuse
to believe that our programs are written in Java. (One of
our competitors has even accused us of lying about it!)
Their reasoning makes perfect sense: Every other Java
program they have ever seen is painfully slow. Our
software is fast and responsive. Therefore it can't
possibly be written in Java. The secret, of course, is
simply that we use AWT instead of Swing. The difference it
makes is remarkable.
Submitted On 05-MAR-2001
anant_s
I think developing AWT further is an important aspect as
said in the bug, and the advantages noted in the bug far
surpass the lopside of it.
We should look at the fact that Even Sun's on Java3D
framework is dependent upon native libraries and this
itself proves Java's native attachment to its platforms.
This give leverage to developers to make use of
technologies that are developed for various platforms and
integrate them tightly with thier java apps.
I vote all hands up for this improvement in AWT
Submitted On 07-MAR-2001
bauer.w
I agree that improvements for the AWT are needed.
There are many platforms that only have AWT , ie. set
top boxes or PDA VMs. These platforms are not likely to
support Swing in the near future, so we have to use
AWT.
I definitely think that there have to be made
improvements on the AWT. When the time comes and
Swing will be widely supported that need decreases,
but until then...
Submitted On 17-MAR-2001
jessh
I agree with some of the issues, but I'm not at all certain
that the solution is to improve AWT.
One way or another, Swing must run faster as AWT is far too
far behind Swing in terms of application building
functionality.
One way or another one must be able to use Java3D and other
justifiably heavyweight technologies in conjunction with
Swing.
I can also see that true floating windows are necesary and
that the only way to accomplish this (including for Swing)
is by extending AWT.
Otherwise, I remain unconvinced that AWT can be salvaged to
the point where it is usable on a cross-platform basis --
the platform dependent bugs in it (e.g. from Netscape to
Internet Explorer to the Sun JRE on Windows to the SGI JRE
on IRIX to....) are simply too overwhelming and too
difficult to reign in based on all the vendors involved.
I would love to attain additional speed by using straight
AWT -- this just isn't real for complex interfaces - at
least not without investing in lots of proprietary
heavyweight component libraries which often don't work as
well as Swing....
Submitted On 22-MAR-2001
zfqjcl
I think awt need includes components such as Tree,
TabbedPane, SplitPane, MessageDialog, ConfirmDialog,
InputDialog, Table, and Icon, ImageIcon, HtmlPane,
certainly, The TextComponents need various Font and Color,
This is very necessary.
Actually, The awt components is very good, not only they
are really native Look&Feel, but also they works very
quickly,and they are very simple to learn and use.
In embed device and PDA , we need gui respond quickly, and
the Java Library is very little.
I like awt rather than swing.
Submitted On 22-MAR-2001
zfqjcl
The awt also includes Toolbar,
And the Class ImageIcon, Icon, GrayFilter, Timer,
TimerQueqe, and The swing event package, and Action ,
etc, if they move to Awt, and above Components add to Awt,
This is very interesting and good, This is very idea ,
Now we write java applet and java application in Embed
device, and PDA, This will help us to work very easy.
Because the java Language is used make programmer write
program very easy, We use awt is very enough, Why we use
swing? In PDA and ReadTime device , the awt is enough ,
We muse write such Tree and Tabbedpane, Why not include in
the core Java awt package?
Please see this and decide.
Submitted On 30-MAR-2001
jan_larsen
I totally agree that awt shuld be kept alive. I think its a
bit overstated that the Swing package is mature, at lately
i have used quite a lot of hours debugging Swing
applications turning up some strange errors in the GUI
elements. While Swing is a cute idea it's just got a lot of
bugs, i think the number of open (and in some cases
declared closed) bug reports on Swing components speaks for
itself.
It really doesn't help my customers, telling them it's the
API i'm using that makes my application heavy with bugs.
Submitted On 03-APR-2001
GrimaceOfDespair
Some people are missing the point of the AWT and Swing.
What is the AWT? A native common denominator between
platforms. This means it makes no sense to implement fancy
stuff like splitter windows, because for example, Windows
has no native support for it. Yet making for instance that
splitter available in the AWT implies simulating the
behaviour in Windows (I don't know if any other platform
has native splitters). Now, what you ideally long with the
AWT is quick platform-native controls and no simulation. In
my opinion, this is a valid reason to restrain to dress the
AWT with all the trimmings (that require timeconsuming
simulation).
And think of it: when you add extra's to the AWT, that on
some platform require simulation, either in native code or
in Java, what else are you building then another Swing
library? Answering: "Building a lighter Swing library"
might be a correct answer, but in that case, you trade in a
lot of free functionality for a lot of (in my eyes
redundant) effort.
I have not actively witnessed the transition from AWT and
Swing, but used both libraries both. I can imagine Swing
must have been a great relief for serious application
developers that were tired of building their own controls
based on the AWT Canvas.
I think for Java's sake it's better to hold on to the
tendency that Pat Niemayer indicated already: aim for pure
Java.
Submitted On 13-APR-2001
jessh
To echo a couple of others comments:
1) Adding weight to AWT means that Java is much harder
to port to new platforms as much more platform
specific UI code must be written. This means that
non-Solaris, non-Windows platform ports will lag
Solaris and Windows even further. It also means
that these ports will be rushed and contain even
more platform specific bugs. Better one set of
bugs to fix and workaround in Swing than 'n' in
various AWT peers!
2) There is nothing to prevent a Swing look and feel from
being a native implementation. I believe Apple's new
Mac OS X (Aqua) Look&Feel uses lots of hooks into
native code -- though I could be mistaken, of course.
Submitted On 13-APR-2001
jessh
Ooops -- adding to my last comment: Nothing besides lack of
heavyweight componentry....
Submitted On 27-APR-2001
praveeng_cet
I totally agree. AWT should be revived. Swing is very slow.
If Swing can come upto the performance levels of AWT, then
there is no reason to continue development of AWT.
Otherwise...
Submitted On 28-APR-2001
asquithea
I used to use AWT for many of my applications on the basis of speed alone. However it became difficult to
continue this due to the lack of features. I can see that not all Operating Systems have the same features
so AWT is limited to a small subset. But I can also see that Swing is Dog Slow on any normal computer
(<128 Mb RAM is what I would consider average for a business machine).
AWT was a hasty development, but for all the time spent on Swing, Swing ended up as a joke. I think this:
Sun must make Swing as fast as the AWT. This may seem like a tall order, but I wrote interfaces in BASIC
for my 27MHz Acorn computer, and they were comperable in speed to the AWT.
Sun should limit Swing to only TWO Look and Feel packages: Metal, and Native.
Metal should look and behave exactly as it does now. Native should mimic the user's system as precisely as
possible. If this means using native file chooser boxes, I would be OK with that, even if it limited the
potential for customising the dialogs. That shouldn't really be a problem though - there are many custom
interfaces around for Windows that manage to be lightweight while looking exactly like the system.
In summary:
Replace the AWT with a non-portable L&F swing feel. Ie: Access to system features where possible in the
same way that the AWT does, but with Lightweight components, and a better range. If we ditch the idea of
having a Windows L&F on a Motif machine (face it - this will never work properly, and most people use
either Metal or their Native L&F) I'm sure this can be done.
Speed up Swing to the same performance as the AWT. If it ran at the same speed, I think the popularity of
Java would explode.
Submitted On 30-APR-2001
dstuart
Largely, I agree with the statements about Swing simply
being better than AWT for almost all tasks.
There is ONE other element to consider, however.
Swing has an extremely large footprint. This can be a
detrement to people that wish to write small GUIs on hand-
held devices, or for web-browsers that don't have swing
built-in. In these scenarios, AWT is a god-send,
particularly when the UIs are simple in nature.
In my opinion, support for AWT should be maintained, or
else there should be a change in the packaging of swing
which would allow it to be moved to hand-held devices more
easily (perhaps a swing-light, instead of the 2 meg
swingall.jar)..
My $0.02
Submitted On 08-MAY-2001
MiguelM
Once I began working with Swing, I never wanted to return to the AWT. I hate it. Utterly. Having said that,
the AWT certainly has its place. My main problem with the AWT is that it doesn't separate the data model
from the control. However, native peers have a big advantage. I don't see why I need to choose between
Swing's Model-Delegator and the AWT's native peers. Swing's PLAF is interesting in principle, but some
components, like their Save and Open dialogs, are very poorly implemented. (They finally look right, but they
don't yet feel right.) On the other hand, the Windows native file dialog absolutely precludes implementing
File Filters. I don't have any problem with Swing's performance, but I'm not writing consumer applications.
(For our internal tools, we get around Swing's performance by using faster machines!) So there are lots of
trade offs, and developers should have choices that offer the most flexibility. The current split between
Swing and AWT doesn't offer that flexibility yet. Would it be possible to write a look-and-feel that uses
native peers? Could Model-Delegator be added to the AWT, or to a new set of components that use the
same native peers? There's a lot that Sun could do to give us more choices. So could a third party
developer. Is anybody out there listening?
Submitted On 10-MAY-2001
ianpaton
Keep AWT alive!! swing components have a massive
footprint, are extremely slow and while i agree that they
look better, often it is easier and more appropiate to use
AWT
Submitted On 19-JUN-2001
slo
I do agree that we need a UI for all the lightweight and
embedded systems, but dont think AWT should be it. Swing?
Not that either, though jedit shows that swing can be fast -
even if that was achieved by writing a new text editor
component.
Submitted On 22-JUN-2001
peastman
AWT doesn't need to match Swing feature for feature to
remain a viable alternative. Swing includes a huge amount
of stuff that I have no need for, and if I need to write a
custom component every now and then to fill in a feature
that is missing in AWT, that is fine with me. The things I
really care about are the ones that simply *can't* be added
by anyone except Sun: menu bars in Dialogs, floating
windows, etc. Give us those, and we can supply whatever
else we need ourselves.
Submitted On 23-JUL-2001
naansoft
No need for enhancements!
AWT is fine for the simple things, Swing is better for the more complicated stuff. Don't overflow the classes
or load time could suffer.
Submitted On 14-AUG-2001
tony_lapaso
Kill AWT and all those who like it.
Submitted On 06-SEP-2001
vxdman
It is very important to have UI's that are completely created and mainatined by Java(swing), and wrappers
on top of OS UI interfaces(AWT). There is a vital need for both sets, and it would be a flaw if Sun were to
ignore the importance of the AWT.
I have, many and many times, had to agree to do UI development in C++/MFC, due to clients disliking the
performance and look of Swing UIs. A more robust AWT would have been the answer to keep Java on those
Client's desktops.
Of course, I would not complain if Swing UI looks/performance was brought up to be identical with a UI
created in C++.
Submitted On 19-OCT-2001
blakis
AWT is old and should be abandoned. The Java engineers
should spend their time trying to make Swing components
faster and smaller (memory footprint-wise) instead of
wasting time maintaining AWT. Then we'd have the best of
both worlds.
Submitted On 19-OCT-2001
lillywhite
couldn't a lot of these issues be sorted out simply by
making it so that the lightweight and heavyweight
implementations interoperate properly? Then you could stick
a JTree onto one side of a JSplitPane, and Buttons and
TextAreas on the other side.
It appears to me that just fixing the problems with mixing
component types would answer most of these requests.
Alternatively, a native L&F would be fine too.
I like Swing's programmatic flexability but I prefer the
native L&F on Windows and OSX.
M.
Submitted On 12-NOV-2001
ctyu
Keep awt alive!
the swing is still too slow.
I can think of two possible solutions
1. implement more awt components and *emulate* the rest.
2. have *native* version of swing.
Emulate AWT
The lowest common denominator wigets is ussless. We could
emulate rest of components we need until they are natively
implemented. This would be fast,complete and have a trully
native look and feel.
Implementing swing in native would maintain all the features
of swing, but would fast, small footprint and java look and feel
Submitted On 15-NOV-2001
SWP
AWT should not be extended for the many reasons listed above.. The solution for those that need native widgets is SWT. SWT, the Standard Widget Toolkit is a library used by the Eclipse project http://www.eclipse.org/
I quote from that page:
"The most succinct description of the Standard Widget Toolkit component is this: The SWT component is designed to provide
efficient,
portable
access to the user-interface facilities of the operating systems
on which it is implemented."
Submitted On 18-DEC-2001
_argv[-1]
How about changing Swing so that it can use native
components, if they are available, and use lightweight
components otherwise. Maybe only do some of the component's
tasks lightweight, if that's necessary.
Pros: No API change. Big speed change.
Cons: A lot of work.
Submitted On 05-JAN-2002
s690716
a good example for an enhanced awt is ibm's swt framework
and eclipse. folks at sun/javasoft... is that not an
incentive, isn't it?
Submitted On 31-JAN-2002
p.lavarre
Hi. I remembered this much-voted RFE when offline I was
asked if anyone had ever answered the comp.lang.java.help
claim from 1998 that:
AWT fails one of the simplest conceivable tests. Just try
using AWT to write the simplest of text editors aka the
Windows Notepad aka Mac SimpleText ... Your results may
then match these dismal results:
Newsgroups: comp.lang.java.help
Subject: AWT 1.1 can't do a Notepad?
Date: 1998/06/25
... I count exactly four major missing pieces precluding
this simplest of applications? ...
1. A callback to let me decide which MenuItem's I want
enabled just before the Menu is displayed or used to
interpret a keyboard MenuShortcut.
Least awful workaround is to capture every key and mouse
stroke and try to keep up?
2. A callback to let me react when the content of the
clipboard changes (not just when some new content replaces
content that I supplied, but whenever the clipboard
changes).
Least awful workaround is to post an advisory when a
clipboard op was chosen and then turned out to be a no-op?
3. Access to the standard File Open/ Save/ Print dialogs.
All right, I suppose I can go reinvent the wheel for these -
the Java file i/o classes do a fine job of letting me
traverse the tree of folders that is a filesystem - but
please tell me someone has already published a wheel I
could reuse?
4. Keyboard "accelerators" for mouseless traversal of the
menu bar and its dropdown menus?
Least awful workaround, given that (3) is largely a Win-
centric problem, is to get by with the workable substitute
for the mouse supplied by Win '95 Start, Settings, Control
Panel, Accessibility Options?
I'm particularly persuaded that I cannot arrange to be
informed only when changes occur in the SelectionStart,
SelectionEnd, or in the text clipped by other apps running
parallel? TextListener does call me when the text in my
own window changes - but not when just [the choice of
selected] text changes. ActionListener and ItemListener
don't call me until after a menu item is chosen.
ComponentListener and FocusListener and WindowListener
don't call me as the focus moves between a work area and
the menu bar - they call me only when my entire window is
affected. ContainerListener calls me when the menu is
defined or undefined - not when it is drawn.
Bottom line is that AWT 1.1 can't do a Notepad?
...
Submitted On 13-FEB-2002
Terrel Shumway
<advocacy>
My workaround: use Python and wxPython: native, fast,
complete, and very responsive to developer RFEs.
(BTW wxWindows also recently added a wxUniversal port which
uses self-drawn widgets. Now you can choose -- *without
changing your source code*.)
</advocacy>
Submitted On 13-FEB-2002
jgoins
I didn't realize how slow Swing was to start-up until I
just recently wrote an AWT app for a handheld. Swing does
not feel slow after it starts, but really does take a
while to begin.
I think AWT should be abandoned for something new, and I
doubt that will ever truely happen. Problem is, AWT
naming conventions were bad, and the overall design is not
up to current Java API standards.
I think all we can do now is make Java faster by sharing
resources (ala dlls) and altering class libs to be static
or dynamic. Machines are getting faster, and swing has
made some very good improvements.
Submitted On 14-FEB-2002
theferret
If you agree with the "sharing resources with dlls" bit,
then go vote for bugid 4416624
Submitted On 11-MAR-2002
mihmax
Pure Java - Yes!
Slow Java - No!
Still, even in 1.4 with it's advertised accelerated
graphics swing is slow (32Mb Geforce 2MX400), so I must
sometimes use AWT for it's speed, and only for this.
Swing should be smaller, now it's too large, having a lot
of functionality of no use. Skinning application is not a
must for big&real-world one.
My proposal: Make standart swing smaller, without an
ability of skinning - only metal and native, and real
native without any mimic, where possible, because it's a
bit strange to work in WinXP and see the Win98!
Cheers
Submitted On 29-MAR-2002
jdoe3000
Swing is ugly, butt ugly.
No I am not talking about the Swing API, though anything as complicated as that can’t be pretty.
I am talking about the Swing GUI.
And not just the so called Metal look and feel we normally associate with a Swing GUI, but the Windows and Motif look and feel also.
The Metal look and feel is ugly, butt ugly. The fonts are ugly, the colors are ugly, the icons are ugly, the borders are ugly, you basically have to reinvent the whole look and feel to get an acceptable GUI.
The Windows look and feel is ugly, butt ugly. It’s ugly because it tries to emulate the Windows GUI but fails at every detail that counts.
The Motif look and feel is ugly, butt ugly. You can’t really blame Sun there because X Window/Motif is already THE ugliest GUI in the world. They are going to end up with the ugliest GUI in the world even if they get every detail right.
I know it’s possible to massage a Swing GUI to look good, but it’s not trivial, and nobody has that kind of time or energy.
Submitted On 24-APR-2002
dleuck
I vote against continued AWT development. By its
creators' own admission, it was a quick solution brewed
under extreme time constraints.
Swing is the future. Javasoft should allocate all of its
energy to making Swing smaller, faster, and more
aesthetically pleasing. Newer computers already run swing
at a reasonable speed and Swings API is truly awesome.
I've worked with a lot of UI libraries and Swing trumps
them all. Going back to AWT is not the answer.
The Metal Look and Feel needs a lot of work. The
foundations are good but it just ain't pretty. If the
Metal look and feel looked half as good as Windows XP or
OS X its adoption rate would improve dramatically.
I also disagree with the suggestion that pluggable L&Fs
should be removed. This is a great feature.
BTW - lillywhite
You _can_ use a JSplitPane and have a JTree on one side
and "heavy" AWT Buttons and TextAreas on the other side.
Mixing becomes problematic when you overlap components (on
the Z plane). A "dragging" JSplitPane divider is actually
rendered on a native component.
Submitted On 25-APR-2002
cwillu
Redevelop swing to allow use of native components is the
upshot.
Submitted On 25-APR-2002
cwillu
The benefit to AWT is the use of actual native components,
and the speed & accuracy that entails. The strength of
Swing is the guarenteed supported of a given widget, and
the benefits of a seperate model. Why not combine the best
of both?
The use of native components should be integrated into
swing: if there is a native FileChooser, use it, otherwise
emulate it. If there isn't a native SplitPane, emulate
it... what do you think native applications are doing?
In this manner we can have the best of both worlds: native
speed and feel when available, seperate data and model, and
all the fancy widgets that users expect these days.
Submitted On 28-APR-2002
briansmith
Please provide a mechanism to vote against bugs so that I
can vote against this one. Please remove all non-top-level
AWT components from Java.
Submitted On 08-MAY-2002
aberglas
So, Why is swing slow in the first place?
1. Because Java cannot pre-compile jars and then load them
quickly as shared pure code like DLLs. It is about time
that we could do this.
2. Java compilers are weaker than C? C# is not slower than
C (or at least it should not be). It is about time we can
do this.
Submitted On 09-MAY-2002
jesperhertel
I am considering starting to develop in Java, because I
like the language.
But it discourages me that the user interface doesn't
seem to use the built-in Windows widgets and dialogs
under Windows. This should be possible, I think. I find
it very important to use native dialogs and widgets. The
Windows GUI shouldn't be mimicked, it should be used as
it is. I find it a very important feature in Windows that
all programs act the same way and uses the same dialogs.
It really irritates me to use Java programs that use
non-Windows dialogs. Mostly the keyboard bindings are quite
different, and because I almost always use the keyboard,
this makes it really hard to use these Java programs. I
very often have to reach for the mouse to do simple things,
like using a File Open dialog.
When running the programs on another platform without the
specific native dialogs and possibilities, these should be
mimicked by pure Java implementations, but only in that
case.
I think Java programs should always run in the native GUI.
It shouldn't be possible to see that it is a Java program.
Also, the Windows feature of placing a "&" in front of
letters in menu items etc. to make that letter a shortcut
key should be implemented. If it were like this, I wouldn't
hesitate so much to migrate to Java.
Submitted On 22-MAY-2002
spau008
Keep AWT alive? Since when was it going to die?
AWT has a purpose, as does swing. The two should remain as
the alternative, yet complimentary, packages that they are.
Whatever AWT WAS when it started, it is that no longer and
is now as much a core part of Java as any other package.
AWT has now become the choice of people wanting fast,
native interfaces with a small memory footprint.(and
newbies ;)
Anything that can add to AWT, without affecting these
things, is a great idea and should be pursued. But that is
true of all enhancements to packages.
the developer quote: "Will continue development." pretty
much sums it up.
Submitted On 04-JUN-2002
jgoins
I have the solution. Drop swing, integrate SWT and AWT.
Believe it or not, this would be the BEST solution to
getting Java on the client. Swing's API is nice, but the
look and feel will cost Sun more time and money to keep up
then using native components.
I vote to drop both AWT and swing and create a SWT+AWT
component with swing like API.
Submitted On 23-JUL-2002
ebkopp
All very relevent comments, except for those who suggested
merging SWING and AWT. It won't work--guaranteed.
Besides, they'd probably have to call it SWAT. :^°
Submitted On 26-AUG-2002
bazsoft
visit www.thinlet.com, they have done an amazing job...
Submitted On 11-SEP-2002
jbcs
Please maintain the AWT at least at its present level since we
and presumably others are making commercial products which
depend upon it.
Since 1997, we have built, enhanced and marketed J42 for
Application Access, a web-to-legacy-host system providing
an Applet which gives a dynamic GUI interface for "green
screen" applications. This is a commercial product sold all over
the world by ourselves and by our OEM partners. There are
many, many thousands of users using it every day.
In this product we dynamically examine each host screen as it
arrives in the Applet and based upon an extensive set of rules
and built-in knowledge of legacy screen designs, we create
on-the-fly GUI forms with which the user interacts. Many
customers use this with host applications containing many
thousands of screens. Literally thousands of different GUI
forms are being created and destroyed as the user moves
through the application. The GUI widgets which we have built
on the basis of the AWT Canvas and Panel are fast and
effective. They also support doublebyte characters. Their
support of doublebyte and other more host application
specific needs go beyond what we could do with Swing, and
in any case we could not tolerate the poorer performance of
Swing (not to mention the cost of rewriting several hundred
thousand lines of code).
We are of course all too familiar with the problems in the AWT
design but we have mastered them.
We have based our entire product line on Java and we need
the basic language upon which we depend to remain intact.
Thanks in part to Java, we have created and maintain a
product which runs in many environments and platforms. Up
to now Java has been the solution for us, please do not drop
essential features upon which we depend and make Java into
the problem.
Bruce Robb
www.j42.com
Submitted On 26-SEP-2002
cdea
-----------------------------
-- My answer to this RFE
-----------------------------
1.) Awt should remain the same.
2.) Swing should have all the bugs resolved.
+---------------------------------------------+
If AWT was to continue that would mean that each
underlining implemention for a specific OS would be with the
jre would have to be constantly updated. The nth OS..., I
believe this would be a maintenace nightmare for each JRE.
That would mean you would have to be on top of changes
with MS, Apple, KDE, CDE, BeOS. You will never get a stable
version.
Awt is for good for gaming, 3D.., platform dependant stuff.
If you want a rich client with true cross platform ability, and
components that don't even exist on Windows, use Swing. VB
can't even get the Windows LNF right. And C# is even worse
then VB. M$ is trying the route of native peers too.
WOROOM - Write Once Run Only On M$.
Do you know how hard it would be to use VC++ to build
translucent components. Swing architecture allows you to
build many skins, and allows the user to experience a rich
interface that windows won't support.
Enless you're happy with WinXP's Fisher Price buttons.
Who really has a great GUI is Apple!
Gee, Swing is an amazing API that will allow you to run
applications on KDE, CDE, and many other window managers.
Think of AWT as the fundamental tools that must exist in
order to have Swing.
If you don't like the LNF buy, create, or use system lnf.
a.) To buy check this site : http://www.l2fprod.com/
b.) To create check this
site :http://developer.java.sun.com/developer/JDCTechTips/20
02/tt0924.html#2
c.) To use defaults : UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
Yes, the guys at Sun should fix the Windows LNF.
But you can fix it yourself if you don't think its perfect. Irony
The guys at Sun fixing Windows... hehehe.
As far as speed goes, The versions Java 1.3.x has improved
(cool), 1.4.1 has greatly improved (amazing!)
If you look at this RFE most of the posts are year 2001. Alot
has changed since then.
Pretty soon, when broad band is everywhere, people will be
tired of HTML,
and you will notice Swing with Java WebStart will be used.
It already is happening.
+---------------------------------------------+
Later,
-Carl
Submitted On 03-NOV-2002
xBryan
I support deprecating AWT and replacing it with SWT in the
runtime. SWT is the best Java GUI libary bar none.
Submitted On 19-NOV-2002
doubleoone
Look at SWT, they also can create a portable native look and
feel, and they also created something similar to Java 2D and
they used that to create tree control for other platform as
well. Try to run SWT and u will amaze their speed and LnF.
They also support more a lot of platform as well. So why
cannot make AWT cross platform ?
soon or later SWT will takeover AWT and Swing if Sun still
don;t to improve it. Try SWT and u will like it!
Submitted On 08-DEC-2002
charlesbronson
Tried SWT, love it. Sun should adopt SWT and integrate it
into the JDK.
Submitted On 29-JAN-2003
peterflynn
Eclipse SWT is a goog example of an AWT style GUI system.
The extra widgets (such as Tree and Table) make it quite
worthwhile for a quick, efficient GUI. The only issue with
SWT is that you have to rewrite your GUI applications if
they've already been written in Swing/AWT. Another
consideration is that you require an additional DLL/SO for the
O/S SWT calls.
Swing suffers due to slow speed (due to the rendering) and
has a large memory footprint. (JTable and JTree are quite
large objects). If the code for these were delegated to the
O/S then not only would things like JTree be faster and take
up less memory.
Perhaps it would be a good idea if Sun implemented their own
SWT based system (building on AWT) and incorporated those
extra widgets into the current API (eventually replacing
Swing). The DLL/SO part of the UI system could be
incorporated as part of the JRE.
Submitted On 06-MAR-2003
jhawkes
If I understand correctly, Swing cannot exist without AWT (it
is built on top of it). I agree with this RFE whole-heartedly. I
would like to see AWT expanded in cooperation with Swing
(something like SWT). Give the programmer the option to use
platform components or to emulate them using Swing. Also,
make Swing faster for God's sake! Why can't Swing
interfaces be rendered using something like OpenGL. Java
should really have an official OpenGL binding. OpenGL too is
an open standard.
Submitted On 17-APR-2003
WiesbauerA
I fully agree with that. I use AWT more often than Swing
because it's faster.
Submitted On 14-MAY-2003
dkf
Just a note in passing: it is theoretically possible to integrate
lightweight Swing components and heavyweight AWT
components together, at least on desktop systems, because
all desktop display systems that I've encountered (being X11,
Win32 and MacOS of various versions) include support for
fairly sophisticated clipping of native windows. I don't know
how easy this would be to integrate with the existing
Swing/AWT architecture though.
Submitted On 16-JUN-2003
Sergey_Salishev
AWT is coded too dirty, if it grow it will finaly become an ugly monstrosity. Sun probably should redesign it, maybe under another name. With better design AWT would be not only faster, but also flexible.
Submitted On 19-JUN-2003
RhysP
The Eclipse project's SWT provides an excellent trade-off
between cross-platform support and a good, fast, usable GUI.
Swing is great as a notion, but is too complex and slow.
On my work PC (dual Pentium III 700 MHz) Eclipse runs well.
It's fast and reliable. Netbeans, however, is painfully
slow. There is a half second gap between pressing a menu
and the menu appearing. This is not acceptable.
The reason is that Swing is simply too slow. Most PCs out
there are not up-to-date: they're years old. This Swing
debate has been going on for years too. It's big, it's
clunky and it's ugly.
Also, you can't rapidly build a GUI. I hate GUI
programming, but it has to be done. In Delphi I can create
a GUI in minutes, no hassle, very intuitive. Why not with
Java? I recently worked out some timescales for developing
a new application. We compared writing it in Java, Delphi
and Clarion. Java was way behind (a whole man year behind)
because of the uncertainties of the GUI programming. We
would love to write it in Java, but it doesn't make business
sense. Such applications are far more likely in the future
to be written in C#.
So, Sun can continue blinkered on their merry way down the
Swing and write-once-run-anywhere route; but they *are*
losing out by doing this.
If they put as much effort into SWT as they did for Swing,
in a year Java could be up there with the best GUI platforms
around.
So, I say no to AWT, no to Swing, and a big YES to SWT!
Submitted On 07-JUL-2003
E.Kopp
I'm confused as to why everybody believes that Swing and
AWT are mutually exclusive entities. I'm probably wrong with
this, but isn't Swing just a wrapper around AWT classes that
adds a bit of key handling, accessibility, and L & F support?
Submitted On 11-AUG-2003
poloi
Agree.
Swing is too fancy.
AWT is too simple.
SWT is great but I can't guarantee support.
Now Sun should improve AWT such that it is as cool as SWT.
In fact, Sun's metal look and feel is really ugly while they
can't improve it because its flat style is simple to draw. They
can never implement fancy stuff like those in MacOS X and XP
efficiently.
I would bet 10 dollars if they are going to implement some XP
features like "Shadow & Fading Menu" in Swing, it would be
slow like hell and no one would use it.
Submitted On 14-AUG-2003
VictorWSS
AWT is fast, easy to use and don't use lots of memory in look-
and-feels. Well, it may sometimes looks ugly, but in the most
of serious applications this don't care. Speed would be
preferable over beauty.
In the otherside, Swing is veeeeeeeeery slow, it's hard to
use, hard to learn and hard to debug and happily eats lots
and lots of memory in stupids and ugly look-and-feels that
you probably would not need or you'll need to redraw it
entirely.
So I think:
1. AWT must stay alive and up-to-date.
OR
2. Swing would be free of stupid, slow, unnecessary and
memory-eater things.
I also thinks that look-and-feels are unnecessary to most of
serious programs (Look-and-feels are for children and gays
only).
Submitted On 10-SEP-2003
prunge
I've been working with Swing for a while now and love it. It
is slow but that is the trade off for having a completely cross-
platform user interface.
For Sun, maintaining Swing is a lot simpler than maintaining
AWT. Maintaining AWT means there is one piece of code for
each platform, Swing runs the same on all platforms.
AWT is too simple to write a decent GUI apart from somthing
that is very simple. Swing has problems with performance,
but that is a tradeoff for it being totally cross-platform. It is
possible to have a well-running Swing GUI. In fact, some
parts of Swing are faster than using AWT. Ever tried making
a list with a twenty thousand items in AWT?
Making an extended AWT places a lot of strain on VM
creators. The good thing about swing is that it doesn't need
to be recoded on different platforms.
One solution would be to create a totally new AWT-like toolkit
that uses a native peer if available, otherwise it paints all in
Java like Swing. And perhaps if someone wanted to use an
advanced feature of component, such as drawing icons in
lists using pure Java, and the native component didn't
support it, then it would automatically change over to the
non-native version. Typically only a few components would
need to do this, as most components such as buttons and
labels would be just simple. In fact, this could simply
delegate to Swing components with the platform's L&F. Of
course this wouldn't be as flexible as Swing is, it would be a
compromise between performance and flexibility.
While this idea would certainly solve these problems, I can't
see Sun building something like this. It would require a lot
of effort that would be better spent on improving Swing.
What we do need is a way to use Swing components along
with heavyweight components. JMF and Java3D are
extensions which come to mind which really need this. I
have only touched on JMF, and haven't tried displaying a
video (just sound), but if I was asked to do this with Swing I
would not be confident as to whether it would work.
Swing will never really be able to keep up with emulating all
native L&Fs. I have heard that MS are going to go all 3D in
their next Windows UI, it'll be very interesting how Swing
will manage to keep up with this.
Submitted On 01-OCT-2003
tquas
Does anybody know only one customer who liked the AWT
"experience"? I never did. Sorry guys, it's too
unprofessional compared to other window systems out there. I
say Drop It!
-tom
Submitted On 13-OCT-2003
compuwinn
I currently use awt within swing and have found that both
have their uses, with swing doing more complex things in
fewer code lines, but in more memory, and AWT doing simpler
graphics things more flexibly, though the code can be rather
long. if Swing becomes much more flexible (especially with
outputting single pixels/shapes) or AWT stays alive, I think
that everyone could have what makes their lives and
programs happier.
Submitted On 15-OCT-2003
Marc__
Dear Sun,
Stop frigging around and incorporate SWT into J2SE!!
- Marc
Submitted On 28-OCT-2003
christopher_j_nielsen
I agree with the other pro-Swingers here. Swing is the way
to go for new UI development -- not AWT. While AWT should
be improved/enhanced where necessary, to improve Swing's
performance -- I would like to see Sun's future development
effort spent on Swing.
Most of the anti-Swing sentiment here seems to be due to
Swing's sluggishness. Folks, what if Swing's performance was
improved to the point where Swing UI's are nearly as snappy
as AWT UI's? Would you all still feel the same way?
Sun -- please focus on Swing bugs/features/performance,
and only enhance AWT where it benefits Swing.
Submitted On 12-NOV-2003
sbatiuk
Java DOES need a GUI library based on native widgets. This
will drastically improve user's experience, performance and
will decrease memory footprint. SWT is a good example how
that could be done. However, it should be based on Swing
API, and NOT AWT API or SWT API. How about
NativeLookAndFeel for Swing?
Submitted On 19-JAN-2004
jessh
To all the SWT fans out there:
How many of you write apps that have to be fast and
*consistently* behaved across many platforms
(Windows only counts as 1 platform)? How does it
behave for this purpose?
As bad as Swing used to behave specifically on one
platform or another this was usually either a VM
deficiency or an platform specific AWT issue. These
are largely clearing up and both VMs and Swing are
faster.
Where there are still issues at least it is all Java code
to debug -- much better than having to debug GTK on
one platform GDI on another and so on...
Submitted On 28-JAN-2004
jernejsre
what about SWT... or Swnig over SWT.
I like Swing very much, but SWT is simply more responsive.
SWT:AWT the first is more alive but not so nice to code.
Submitted On 28-JAN-2004
jernejsre
what about SWT... or Swnig over SWT.
I like Swing very much, but SWT is simply more responsive.
SWT:AWT the first is more alive but not so nice to code.
Submitted On 15-MAR-2004
mikaelstaldal
It seems like many thinks that it's important to have
applications behave consistently across platforms.
However, I think it's also important to be able to
develop applications which behaves consistently with
other application on the same platform. And that can
only be done with AWT, not with Swing.
Submitted On 17-MAR-2004
ravneetg
I think it should be kept alive and more efforts should
be put into AWT to let the community use more of it in
real apps.
Submitted On 21-APR-2004
JessHolle
Much of this argument is dated.
Swing is fast -- see NetBeans 3.6 on reasonable
hardware (even compared to the much hyped SWT).
Swing can look and feel nice -- again see NetBeans
3.6.
So why keep fighting this? Move on and be happy with
one full featured GUI API.
Submitted On 21-MAY-2004
chrisharlow
I dont need AWT enhanced BUT I DO need people to stop messing with it. It seems that every new version of the plugin creates some new bug or problem in code that previously worked just fine.
Having done the deal with Microsoft to contunue the MSJVM license another few years Sun have effectively forced us ISVs to continue to use AWT and guess what... awt on the MS JVM works MUCH better than awt in the Sun plugin!
Submitted On 02-JUN-2004
aoborges
I Agree.
AWT must grow. Vote for improve lower memory footprint, and more input gadgets.
See IBM's SWT: fast, low memory footprint makes Eclipse the ideal IDE for low end machines at schools and colleges.
Swing is good, but it is also TOO MUCH HEAVY !!
Submitted On 22-JUN-2004
steve_va
Hi
AWT can still be there for backward compatiblty but for nothing else!
Let us all together much effort for keeping Java really pure 100% Java.
The last thing java needs is a "toolkit war".
If you need native feeling, please use native C++ MFC etc.
Swing is really flexible and fast.
see IDEA 4.0 (www.intellij.com).
Who says, native feeling cannot be done 100% with lightwight Swing !?
You want to have 100% native app e.g. Visual Studio .NET feeling on EVERY platform ?
See JIDESoft (http://www.jidesoft.com/images/dock.png)
You want 100% native swt eclipse feeling ?
See www.jgoodies.com http://jgoodies.com/freeware/metamorphosis/images/elegantui.gif
or http://jgoodies.com/freeware/skeleton-pro/images/skeleton-pro.png
Have fun.
Submitted On 22-JUN-2004
steve_va
Somehting more:
of course memory footprint and performance of ui is critical, but java is getting faster in each new release and today's available hardware is getting better and IS more than enough for responsive ui.
When using "old" slow machines, then you must live with memory/performance problems of 100% pure java apps. these problems are just normal with that old machines.
Submitted On 16-AUG-2004
jb6494
I am a full time swing client developer. I would like AWT to go away, but why not use the structure of swing to create a native level L&F? Use the same features but they would map into a native backend.
This would accomplish several things.
First, it would allow developers like me to continue to leverage out investment in swing.
Second, it would provide the ability to create "native apps" that respond correctly to the OS desktop.
Swing apps in the windows L&F not only look different but they perform differently that native.
SWT would have been much more usable if the documentation had been better and if it had maintained the swing signatures where possible.
Submitted On 13-SEP-2004
zz82
I suggest make AWT to be things like SWT, and keep Swing in front of the layer where AWT/SWT/something lies. Swing remains lightweight unchangedly, which AWT's functionality extended to that of SWT's power.
Submitted On 30-SEP-2004
jtr
jb6494 is absolutely correct! A native swing L&F would combine the accuracy of a L&F (especially the feel) with the excellent swing API.
Submitted On 13-OCT-2004
ulasergin
I strongly agree wýth this comment.AWT imporovement must continue.Swing must not be the only choice left to the developer in order to client-side java to survive.
Submitted On 13-OCT-2004
ulasergin
I strongly agree wýth this comment.AWT imporovement must continue.Swing must not be the only choice left to the developer in order to client-side java to survive.
Submitted On 27-OCT-2004
billyea
The problem is that, while AWT can directly hook with the native L&F, is fast, and efficient (but that is questionable), but unfortunately AWT is definitely NOT PORTABLE. Also Java
Submitted On 19-APR-2005
JessHolle
I cannot believe this enhancement still has so many votes.
The Eclipse team even seems to admit that SWT was a bad idea in that Swing now performs quite well. Though there are a lot of rabid SWT supporters, their claims that it is much faster than Swing are baseless in recent (e.g. 1.5.0_02) JVMs.
The only real point I can see to this whole enhancement is cleaning up the interaction between Swing and things like Java 3D that require heavyweight components. I've used native UI frameworks wherein GL (pre-OpenGL) was freely used in rendering UI components (for cool effects), etc, whenever desirable -- whereas the tension between Swing and Java 3D would seem to make this impossible.
Submitted On 07-DEC-2005
tpm476
i think AWT should be kept alive, since it is one the first GUI APIs for java. Not only that, there are real situations where developers really want speed over looks. It is quite true that enhances to the AWT will burden SUN, but another concern is that will such enhance actually cause perfomance issues ? I have to vote that AWT should be kept alive due possible performance boost over swing
Submitted On 14-DEC-2005
Sheepy
SWT maybe less useful now that Swing and Java see extensive improvements, but it was a right decision. Without it, and without a fast Eclipse supported by it, Java may not enjoy the popularity it now does.
As for keeping AWT alive, it is actually two requests: do not remove AWT from the library, and keeping AWT up-to-date.
AWT is an integral part of Swing. I would assume it is going to stay for a long long time, long after most of us have stopped worrying about it.
As for keeping AWT up to date, as stated in evaluation it is too general and should be separate into more specific requests, be its speed, competibility, feature requests, or other things.
Swing is not doing a bad job now, and is much more flexible. I would prefer that effort are spend on fixing things with no workarounds then with AWT which for performance can be replaced with SWT.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
