Skip to main content

Replace AWT with SWT ?

41 replies [Last post]
gcollin
Offline
Joined: 2003-06-10

SWT is far better than AWT. It supports more native widgets.

So I think it can be quite interesting to use SWT instead of AWT.

Moreover, implements Swing components using swt. I like the Swing API but would rather use the native widgets swt offers.

Just my .02
G

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
angben
Offline
Joined: 2004-10-07

> Sun's Java Web Start secure sandox will never let an
> application use native libraries. The SWT folks will
> just have to accept defeat here.

That's not true. You can deliver native libraries with Java Web Start, the publisher only needs to sign the JAR containing the libraries and the user needs to approve of this when downloading the application. This has been a part of JWS for a long time. Go back and read the JWS docs.

markswanson
Offline
Joined: 2003-06-11

> > Sun's Java Web Start secure sandox will never let
> an
> > application use native libraries. The SWT folks
> will
> > just have to accept defeat here.
>
> That's not true. You can deliver native libraries
> with Java Web Start, the publisher only needs to sign
> the JAR containing the libraries and the user needs
> to approve of this when downloading the application.

Perhaps I could have worded this better. By mentioning "secure sandbox" I was talking about secure unsigned applications in the JWS sandbox.

Secure unsigned applications in the sandbox can not use native libraries.

markswanson
Offline
Joined: 2003-06-11

I can agree to disagree about securing SWT, but the SWT folks also need to consider this:

Sun's Java Web Start secure sandox will never let an application use native libraries. The SWT folks will just have to accept defeat here.

Also, the SWT folks face a hill that is growing steeper every day: people are (rightly so) starting to distrust native code. I don't trust the SWT libraries. This isn't anything against the SWT authors. I simply don't trust native code, period. Why should I grant someone full access to my machine when it's possible to provide the same functionality within a secure sandbox?

Cheers.

dog
Offline
Joined: 2003-08-22

hmmm. You assume that there no longer will be normal desktop apps. If I were writing a word processor or spreadsheet or something like that I often would need access to potentially harmful things (like reading/writing files). In fact, I could hack you without access to native code simply because you gave me access to your boxes' files. Sandboxing doesn't work in all cases and for many apps we don't care about sandboxing..

does your IDE run sandboxed?

markswanson
Offline
Joined: 2003-06-11

> hmmm. You assume that there no longer will be normal
> desktop apps. If I were writing a word processor or

I am not assuming this. In fact, I'm the author of ScheduleWorld - which is a normal desktop app that lives entirely in the sandbox.

> spreadsheet or something like that I often would need
> access to potentially harmful things (like
> reading/writing files). In fact, I could hack you
> without access to native code simply because you gave
> me access to your boxes' files. Sandboxing doesn't

You just stated the key: "because you gave me access". All I want as a user is to be given the choice. BTW, reading/writing files works fine within the sandbox, and doesn't require any explicit permission from the user unless you want to read/write outside the protected area.

> work in all cases and for many apps we don't care
> about sandboxing..

_you_ don't care about sandboxing.

> does your IDE run sandboxed?

No, it's a native app.

Should all Java applications run with a SecurityManager? Most definately yes. Even a Java game using OpenGL libraries does not need to access my entire machine - only read/write for the directory it was installed in. Socket access? Sure. The ability to sniff keystrokes outside of the game, or install spyware/viruses, sniff packets: no.

Sun is making enhancements to the sandbox all of the time. Soon a SocketService will be available. Perhaps with enough votes more fine-grained permissions would be allowed. The sandbox isn't perfect, but it has so much potential. The point of most of my sandbox/webstart postings is: let's work with Sun to make it the defacto environment. Any corporation or individual that even cares a little about security will give points to applications running in such an environment. I'm willing to work towards such an advantage. Who wouldn't?

rivasdiaz
Offline
Joined: 2003-06-11

> First off,Have you ever even worked with the Swing
> API or SWT? Do you use any Java desktop applications?
> Doesnt sound like it. Swing looks more native than
> SWT from java 1.4.2 upward.

Of course you haven't used Java 1.4.2 on Linux right?
Change the theme on a GNOME session and look to a running java Swing application. Or easier, use a customized theme and run a swing application.

> Secondly, the swing api is more mature than swt by a
> longshot, swt requires a lot more custom components
> and is nowhere near to the same scope of swing.

right.

> Lastly, SWT requires releasing resources by hand,
> i.e. no garbage collection, this is a step BACKWARD
> not forward. Now I understand the want for better
> performance and more native appearance but swt is not
> the answer we as a community are looking for.

right.

What I want from AWT:
1. Add support for more native components (trees, tables)
2. Update the look and feel: support for Windows XP and GTK/GNOME on AWT.

If Java AWT where updated, SWT usage where reduced a lot. If developers are looking for SWT is because standard Java is missing something.

denismo
Offline
Joined: 2003-06-28

I agree with "What I want from AWT", both 1. and 2., we are looking to satisfy these needs, though I, as always, can't promise anything.

markswanson
Offline
Joined: 2003-06-11

> The Mono project is particularly an example of this.
> Why would the Linux community look for using a .Net
> C# port for rich clients rather than Java which is
> already there ... because they have stated right out
> that Java does not provide the needed rich client
> experience, nor does it allow close enough
> interaction with the system level -- yet they still
> want something that is cross-platform along with

Who is "they" ?

A couple of 15 year old anonymous cowards on slashdot plus one organization does not define or speak for the Linux community.

Slightly OT: I think one major barrier is Sun making collossally stupid mistakes about virtually everything Swing/desktop related. Sun still refuses to support KDE and will only create JWS icons or associate JWS mime-types in GNOME.

sumitkishore
Offline
Joined: 2003-06-10

> The Mono project is particularly an example of this.
> Why would the Linux community look for using a .Net
> C# port for rich clients rather than Java which is
> already there ... because they have stated right out
> that Java does not provide the needed rich client
> experience, nor does it allow close enough
> interaction with the system level -- yet they still
> want something that is cross-platform along with
> java-like language features -- so they spend over 3
> years creating an Open Source .Net implementation.
> There are other reasons of course, and it's a very
> cool project, and even integrates Java, but there's
> something to be said about the fact that NO one uses
> Java on the desktop in the linux community because
> it's UI is just horrible. Plain and simple.
>

That might be a worthwhile argument after we get a look at what exactly Mono's look-and-feel proposition is on all Mono supported platforms. It's still some distance from getting there.

Sumit.

andrepm
Offline
Joined: 2004-10-25

First off,Have you ever even worked with the Swing API or SWT? Do you use any Java desktop applications? Doesnt sound like it. Swing looks more native than SWT from java 1.4.2 upward.

Secondly, the swing api is more mature than swt by a longshot, swt requires a lot more custom components and is nowhere near to the same scope of swing.

Lastly, SWT requires releasing resources by hand, i.e. no garbage collection, this is a step BACKWARD not forward. Now I understand the want for better performance and more native appearance but swt is not the answer we as a community are looking for.

vhi
Offline
Joined: 2004-10-11

>> Swing looks more native than SWT from java 1.4.2 upward.
How can that be, considering that SWT uses Win32 APIs? You mean that Swing is more native than Win32?

>> SWT requires releasing resources by hand, i.e. no garbage collection, this is a step BACKWARD not forward
Actually, this is a problem only when you use Font, Color etc. Most of the widgets are disposed off when the top window is closed so you don't have to explicitly dispose them off.

murphee
Offline
Joined: 2003-06-10

Look at Eclipse for instance. They abandoned a 100% native look and feel with 3.0, and they changed their icon set.

BTW: in case you hadn't noticed, SWT doesn't use too many native components, as they provide a lot of custom rendered components as well (just look at the horrible curvy tab headers and other more complex components like the Forms UI which is used, for instance, in the PDE).

I suppose you can stay clear of many of those things, but you can also make Swing look like a native 32 bit app, if you really need to.

About releasing resources:
This really bothers me, especially as it's not necessary for Colors (it was only added because some X11 versions need to have colors requested and returned to the system; on modern systems and Win32 this is not necessary, so basically the whole dispose() nonsense for Colors is pretty
silly).

tsinger
Offline
Joined: 2003-06-10

> Eclipse looks and feels so good because of SWT.

Wrong. Eclipse looks and feels good, because capable developers and GUI-designers (the people, not the tools) are responsible for the GUI. But Swing-GUI can be as good looking and feeling as well - see www.jgoodies.com or www.jformdesigner.com for examples.

Also take a look at the opposite examples: dumb developers using Windows' API: I guess, you know a lot of ugly and difficult-to-use VB- or Delphi-software.

BTW, we are developing a surveying, desktop software and I had to teach some customers 1 1/2 months ago. Nobody complained about the (Swing-) GUI. For end-users a good usability is much more important than native looking. And native look and feel does not automatically mean, that the application has a good usability. Always, with Windows-API, SWT or Swing, developers are needed, which understand GUI-design and usability.

Tom

bfandreas
Offline
Joined: 2004-10-26

Agreed. You always have to have the user in mind.
As a developer, I'm quite uncomfortable designing an app from the top down. But in most cases it's better to do a GUI demo first and let some real users have a go.

Another thing is that many novice developers forget that you have to decouple time consuming operations from the UI thread. It shows especially in Swing. Do a 5 Gig download in the UI thread? Impatient user moving your app on the screen will get a gray window. That's where Swing got its bad name from. Poorly implemented toy apps whipped together on a whim.
If you want to do it correctly, you'll need to have a plan for both your application and the UI. That's true for any UI API, but in Swing cluelessness immediately shows.

markswanson
Offline
Joined: 2003-06-11

> > There is no need to replace AWT with SWT, and it
> is
> > impossible, due to the many reasons.
>
> Just how is it impossible? What are the "many
> reasons"?

You can not build a secure application with SWT because it uses native libraries.

angben
Offline
Joined: 2004-10-07

> You can not build a secure application with SWT
> because it uses native libraries.

I agree that SWT would need a review to block off / constrain access to unsafe OS APIs that are currently exposed.

However, as a layer between the native widgets and the application, SWT could enforce security. Java is implemented on a VM which, ultimately, uses native library calls to fulfill functions like opening and closing files. Does that mean that the VM is insecure? No, only that the abstraction layer that the VM provides needs to be smart about security.

It is true that SWT has security issues in its current form, but I don't think they are insurmountable.

markswanson
Offline
Joined: 2003-06-11

> It is true that SWT has security issues in its
> current form, but I don't think they are
> insurmountable.

I can agree to disagree simply because historically the task you are describing has proved insurmountable. In 1995 I was starting to wonder if I was ever going to see the end of security alerts and patches. I have long since given up hope.

Non-executable stacks, and many other tricks help move towards more secure environments for native code, but we are far from living in a world where native code can be trusted. I think the SWT folks should just openly accept this as a wart in a world where all software has warts and let the users decide if this is an acceptible tradeoff or not. I suspect (and openly hope) that because of this wart no one will use SWT for anything and it will simply go away.

angben
Offline
Joined: 2004-10-07

> I can agree to disagree simply because historically
> the task you are describing has proved
> insurmountable.

Not at all. The Java libraries themselves have native methods, and the VM itself is written in C. It's not the presense of native methods that causes security issues, its what those methods do.

In places where SWT exposes native calls (eg. Win32 messaging mechanisms); this can be mitigated by the Java security API or simply not exposing these mechanisms outside of the SWT layer itself. Places where SWT exposes functionality that itself is dangerous, (e.g. BitBlting the desktop into a buffer, potentially exposing private information to an app); here again, using a security manager or simply not exposing this functionality can address the issue.

Anyways, we'll have to agree to disagree because I am unconvinced there's anything going on in SWT that cannot be solved with tweaks to the design.

carmello
Offline
Joined: 2003-09-10

"but personally I don't see a standard Java IDE plug-in architecture until J2SE supports BOTH SWT and Swing in an interoperable fashion".

You could write a plugin that does the logic and two other plugins that does the UI, one Swing, the other SWT.
By default you could start with Swing and allow the user to switch to SWT.

angben
Offline
Joined: 2004-10-07

> You could write a plugin that does the logic and two
> other plugins that does the UI, one Swing, the other
> SWT.
> By default you could start with Swing and allow the
> user to switch to SWT.

True, but how many plugins do you see out there like that? The user interface can be a big chunk of the code; who wants to write that twice? If Sun adopted SWT as a replacement for AWT, and then makes the two interoperable (see links in this thread to SF.net projects doing just that), then plugin developers can code to the API they prefer (SWT or Swing) and give the user the choice of whether they want pure-Java (Swing) or native widgets (SWT).

Or you can rewrite your UI twice just so you can support both Netbeans and Eclipse in their native UI. /shrug

josgood
Offline
Joined: 2003-06-18

I'll be so thrilled when the peanut gallery finds a new chew toy. There are exactly three ways to do a user interface kit:

Bridge - AWT
Facade - SWT
Emulation - Swing, JFace, Thinlet

Each has pros and cons. No one is best.

Rewriting Swing to remove the dependency on AWT is still worth debating.

And extra credit will be awarded to anyone who unifies the APIs such that a developer could choose between AWT, Swing, and SWT/JFace without a rewrite.

Otherwise, now, if you all don't mind, could we talk about something relevant?

teodorbaciu
Offline
Joined: 2004-10-26

Successful companies know that if they want to have further success they need to listen their customers wishes.

The relationship between Java developers and Sun resembles in many aspects to the relationship between a company and its components, for various reasons. Now Sun has two choices:

1. Ignore the wishes of this growing comunity who needs access to native UI components.

2.Include SWT in the Java SDK and let the java developers decide which gui implementation suits best for them.

If Sun decides to go with the choice No 1 then it will face the consequences that any company faces when ignores its customers. But if Sun would include SWT in the JDK that would attract developers from other technologies, like VB and Visual C++ developers, who could build cross platform native looking applications in Java.

Message was edited by: teodorbaciu

Message was edited by: teodorbaciu

cowwoc
Offline
Joined: 2003-08-24

My bottom line is this:

I want Swing to have the ability to use the native implementation of widgets like SWT has, but I don't want SWT. I feel this is important because Sun's current implmenetation of the Windows L&F will *never* feel 100% native. They will always be a step behind and furthermore they cannot support the situation where plugins install themselves into the explorer context-menu. Any sort of 3rd-party software that is meant to show up in a file explorer view will not show up.

My motivation for enhancing Swing with SWT-capability is not for performance, but rather for "good design and correctness". The "correct" behavior is for Swing to fallback on native widgets when the user requests a native L&F. It is a waste of Sun's resources playing catch-up fixing L&F bugs. Lets just fix the design *once* and be done with it!

dog
Offline
Joined: 2003-08-22

This is the old native vs. reimplemented debate that the Smalltalk world had. The people from VisualWorks and the like preferred to reimplement the LAF, whereas IBM (actually OTI, yes.. the same people that wrote Eclipse) preferred to go the native route. OTI is surprisingly good at its native implementations.

People have to remember that different people use Java for different purposes. For example, for many Windows is the main target platform, and they only need a "Linux story" to get by. Maybe they use Java to allow faster development cycles (vs C++). Maybe they want to native compile to small executables.

Swing's losing battle is to keep up with the multiple platforms it reimplements, SWT's is to provide more and more platforms it will run on. But both, in reality, are bound in the number of native LAFs they can provide.

I'm happy I have a choice.

carle
Offline
Joined: 2004-05-24

I understand there are SWT performance issues on Macintosh and Linux systems. Have these issues been corrected?

angben
Offline
Joined: 2004-10-07

I can't speak to OS-X, but I run Eclipse 3.0.1 under Gnome on Linux and it is very speedy; comprable to C/Gnome apps.

It's much much faster than Netbeans/Swing on Gnome, not to mention first-class support for Gnome themes, which Swing *still* doesn't have right with JDK 5.0.

SWT in the Eclipse 3.1 betas running JDK 5.0 screams. And that says a lot given how fast Eclipse 3.0 with SWT runs.

I do know there is currently an issue with embedding Swing in SWT under OS-X; something to do with the event handling. I don't think that's what you're referring to, though.

vhi
Offline
Joined: 2004-10-11

The application I am working on is developed in SWT. Along with the JSmooth utility, I was able to create an application that was entirely developed in Java, but one which integrates nicely with Windows. The users simply cannot distinguish between a native application and my Java application. Which is a Good Thing.

I know that there are some compromises to be made when creating a cross-platform application. But making the end users compromise is plain arrogance. There is a need for a native UI. There is a need for a native application packaging mechanism. To ignore it is fruitless. The reason Desktop Java spells nightmare to the end users is the annoyance of fiddling with 'bat' files and the ugly looking (so called native LAF) GUIs.

zander
Offline
Joined: 2003-06-13

> I know that there are some compromises to be made when
> creating a cross-platform application. But making the
> end users compromise is plain arrogance.

Its plain arrogance to stick the Linux users with the bad looking GTK toolkit and expect them to like it. Even Swing-ocean looks better then that.

Going cross-platform; there is no such thing as 'native'.

> There is a need for a native UI.
I'm not sure why; all the reasons I have heard people post all boil down to one thing. The Windows L&F on Swing has a lousy set of usability features which make the L&F not feel like Windows at all.

Look at all successfull UIs; they surely don't look native, but they implement all those silly little usability details.

My (an my companies) experience with a cross-platform l&f with many, many usability features has been very good, and I am convinced native is just a fad untill a good feature-loaded L&F for JavaSwing comes out.

marc_
Offline
Joined: 2003-12-30

The point is that there should be a [i]standard[/i] API. Yes, Swing and SWT have different [i]implementations[/i] useful in different situations, but there is no good reason to have a two or three different APIs for creating a button or a combo box.

This fragmentation is hurting desktop Java.

monika_krug
Offline
Joined: 2004-10-14

The shift from AWT to Swing resulted in API fragmentation anyway, did it not? Another API won't hurt any more than that did. That the result looks and feels nice is a lot more important than a non-fragmented API.

Monika.

marc_
Offline
Joined: 2003-12-30

Yes, the shift from AWT to Swing was fragmentation also. The SWT/Swing split is even more painful because a) the API is much larger now; and b) there is no clear 'winner' - you end up with 75% developers knowing Swing and 25% knowing SWT (insert your own ratio).

And yes, the user experience is more important than having a single API: I prefer SWT to use and code against and would much rather have two APIs than a single one that doesn't have true native look and feel. But surely the ideal is to have a single, dominant API encompassing [i]all[/i] the implementations?

In five year's time, either the Swing or SWT (or a hybrid) API will be dominant like Swing is currently dominant over AWT. And that is a Good Thing!

angben
Offline
Joined: 2004-10-07

SWT and Swing could live side by side very comfortably. For example, one could provide an implementation of SWT which uses Swing as a 'native widget set'. Therefore, SWT could run anywhere Swing runs. One could choose at run time whether they wanted SWT to make use of Swing or the underlying native widget set. Similarly, Swing could delegate to SWT. In fact, there are SourceForge projects aiming to do both of these things. This cooperation between SWT and Swing would allow users to choose the API they feel best suits their needs, and the implementation (native vs. emulated) that best suits their needs. Freedom of choice is what makes Java a strong platform.

Why does this matter? Again, it matters because it allows developers to work with the API that suits them, and reap the benefits of both portability and native L&F, although it would be a decision at run time which was important to the person running the application.

I use both Eclipse and NetBeans. Both have thier strengths, but personally I don't see a standard Java IDE plug-in architecture until J2SE supports BOTH SWT and Swing in an interoperable fashion. Sorry, but I want to use SWT. If that means that my plugins are Eclipse only, so be it.

Remember, SWT and Swing address different problems. Swing fulfills the promise of "right once run anywhere" UI, where the tradeoff is some native L&F. SWT leans the tradeoff in the other direction.

Again, pointing to the projects on SourceForge, the two approaches do not have to be mutually exclusive, provided that one realizes the tradeoffs and J2SE builds interoperability between the APIs. This would not be a minor undertaking, but it is absolutely necessary for healing a very important schism in the Java community.

The good news is that both SWT and Swing are great at what they do. The bad news is, both sides need to put away their egos and build a bridge between the two. Then everyone wins.

I shouldn't need to laud Swing on Java.net, so I'll take a minute to say something good about SWT. SWT works and works very well. Eclipse is a beautifully comfortable application to use because it uses native widgets. When I put Netbeans side by side with Eclipse, Eclipse wins hands down in UI L&F. It's no contest to me. However, I still see the benefit to Swing in that Netbeans doesn't have to use a dated Motif L&F on platforms like Solaris. Again, it's all about trade offs.

J2SE supporting both SWT and Swing would be a crushing blow to .NET. Indeed, it is pretty obvious to me which UI framework will be first to deliver an up-to-date L&F on Windows when Microsoft delivers Avalon. Surely Sun must realize that SWT will be able to mimic the Avalon L&F years before Swing, because SWT will simply USE AVALON.

Please Sun, realize that while Swing is great, it is not the end-all-be-all of widget frameworks, and AWT needs a worthy successor. You can do this in the timeframe of Mustang because IBM has already done the hard work. Let SWT be AWTs successor.

Thanks for listening.

denismo
Offline
Joined: 2003-06-28

There is no need to replace AWT with SWT, and it is impossible, due to the many reasons.

In Tiger, the "bridge" has been developed, allowing SWT to embed Swing. So you can use either SWT or Swing, or you can mix them when you need that. However, as you pointed out, Swing and SWT won't look and won't behave the same, so the possibilities to mix them efficiently are quite limited. And if you don't plan to mix them - then what is wrong with SWT being developed as OS product separately?

angben
Offline
Joined: 2004-10-07

> There is no need to replace AWT with SWT, and it is
> impossible, due to the many reasons.

Just how is it impossible? What are the "many reasons"?

What it boils down to is choice. Sometimes native widgets are the right choice, and AWT is very weak at the moment. Java needs an up-to-date native widget implementation and SWT fits the bill. The fact that SWT and Swing can run side by side, or even on top of one another, is quite nice as well.

http://sourceforge.net/projects/swingwt/
http://sourceforge.net/projects/swtswing/

andrepm
Offline
Joined: 2004-10-25

If you said this 5 years ago i'd say you have a point, maybe...but Swing has really come a long way, and is improving every release, while SWT is really starting to show its age and seems pretty stagnant.

benjc
Offline
Joined: 2003-12-07

Umm, how is SWT showing its age? SWT != AWT. SWT is the native widget toolkit at www.eclipse.org.

Since it just had a 3.0 release a couple months ago with significant improvements on multiple platforms (OSX & Linux ... beyond the obvious windows) ... I wouldn't say it's stagnant at all.

Eclipse looks and feels so good because of SWT. Swing is getting better, and with effort can look and feel alright, but even the much improved Netbeans 4.0 doesn't quite feel right ... look at OSX for example.

Sun/Java really messed up on the desktop, and it has both technical challenages and very negative perception in the industry to surmount if it's ever to be a player in rich client applications.

The Mono project is particularly an example of this. Why would the Linux community look for using a .Net C# port for rich clients rather than Java which is already there ... because they have stated right out that Java does not provide the needed rich client experience, nor does it allow close enough interaction with the system level -- yet they still want something that is cross-platform along with java-like language features -- so they spend over 3 years creating an Open Source .Net implementation. There are other reasons of course, and it's a very cool project, and even integrates Java, but there's something to be said about the fact that NO one uses Java on the desktop in the linux community because it's UI is just horrible. Plain and simple.

Java rocks on the server, but doesn't quite cut it on the desktop. I love java, but I kind of hate using Java desktop apps -- they're horrid to work with and don't look right .... and we can't really claim that every java developer is that bad at what they do. They've tried hard on Netbeans, and it still doesn't cut it.

So, SWT is a saving grace for rich clients in the Java world when something needs to look at least half way normal -- and it's maturing, not stagnating.

Ben

teodorbaciu
Offline
Joined: 2004-10-26

I agree with you when you say that we need SWT for building rich clients.

Right now it's just too hard to build nice looking and responsive GUI apps using Swing. And no matter how hard you try, a swing application would look and and behave different, and the user perceives this.

When considering the most downloaded java application, the one with most downloads is not JBoss, or Tomcat, but Azureus, a bittorent client with millions of downloads per month. And part of this success comes from the fact that it's gui is implemented using SWT.

If we could do a poll on users of a java application to see what UI they like more, the one done in Swing and the one created with SWT for the functionality, I am convinced that 90% would prefer the SWT GUI.

vhi
Offline
Joined: 2004-10-11

I would also like to see the demise of AWT. SWT is what AWT should have been. But I really doubt if this would happen because:

1. Eclipse.org has not submitted SWT as a JSR. They do not have any plans to do so either.
2. As long as Sun controls the development of Java, SWT will not be incorporated as it would effectly mean the end of Swing (Swing became popular because AWT was too limited).

haug
Offline
Joined: 2004-10-11

No i don't think one will dominate the other. SWT and Swing have there pros and cons.
Swing is not native, that means all applications look the same on all platforms. If you want a corpered identity for your applications you are lost with SWT, it's simply not possible. On the other hand if you want native look and feel you better use SWT.
Customizing Swing components is quite easy, doing the same with SWT is a pain because the components are native.
Thinking about testing, SWT applications testing effort is linear with the number of platforms you support.
SWT feels a bit snappier on most platforms because of the platforms optimizations in their native libraries.
I think SWT and Swing should both exist and they should use the same native interfaces. Swing needs some native interfaces anyway, and SWT would win a better tested base library.

ahoma
Offline
Joined: 2003-06-20

Agree. AWT is a decade old, and it should be removed.
Build Swing on top of SWT it will give us finally a Java desktop application.

johnreynolds
Offline
Joined: 2003-06-12

Is this feasible? Sounds like a great unifier if it is.