Fog Creek Software
Discussion Board




SWT is hot!

Eclipse 3.0 is just out, and boy, does it bring some changes. While SWT used to be an immature technology, now it has grown and matured. The widgets look complete and stable. It's now possible to mix lightweight and responsive SWT widgets along with the good old Swing widgets (although, after thinking about it, I don't see why would anyone want to do that, but it's a Good Thing, marketing wise).

With the exception of developer tools, I have never seen Swing apps on the wild, and the few I saw were ugly, clunky and unresponsive. Imagine what won't change with SWT.

And if you're like me, you just want Java for it's syntax and don't give a damn about WORA, you can always compile your java apps with gcj and produce a standalone windows .exe.

Let me give you an example that I've had kicking around my head since last night: I'm a server side java developer who's been having an idea for an app for the past few months. Build the UI in SWT and using JNI I would tune the tricky parts in C (remember that WORA is out). Since I don't want the user to install the JVM, I'd compile it with GCJ and voilá!


Sorry, this seems so good I had to share it. Flame at will.

RP
Monday, June 28, 2004

This is the link that inspired me:
http://www.cs.umanitoba.ca/~eclipse/

RP
Monday, June 28, 2004

Ok, I'm a Java n00b, so... what's wrong with Swing?

muppet from madebymonkeys.net
Monday, June 28, 2004

>Ok, I'm a Java n00b, so... what's wrong with Swing?

Well nothing really, it is just hard to grok and it doesn't look-n-feel like native. And if you haven't groked swing and write applications in it the applications ends up feeling very sluggish!

MyNameIsSecret();
Monday, June 28, 2004

Swing is great.  Try JGoodies if you want it to look nice.  Learn how to program it and don't expect the toolkit to optimize your code.

name withheld out of cowardice
Monday, June 28, 2004

who expects their tool to optimize their code?  Seriously?

Then again, I come from a perl background.  No fancy compilers pulling optimization tricks there.

muppet from madebymonkeys.net
Monday, June 28, 2004

what's JGoodies?

heading to Google...

muppet from madebymonkeys.net
Monday, June 28, 2004

Well, MVC and Layout Managers aren't very popular for a good reason: they aren't meant to be popular. ;-)

If you compare Swing to VB, you will understand the difference.

But there are good guys that try to make it easier, so a look at JBuilder may be valuable.

I do drink caffeine
Monday, June 28, 2004

GCJ is incomplete.  Some java code won't compile if you make use of certain packages and features.

NoName
Monday, June 28, 2004

It seems to me a lot of people expect the GUI kit to optimize the code.  You tell them that Swing can make nice responsive GUIs and they complain you have to be an expert.

JGoodies is a project some guy did that makes really nice looking Swing GUIs.  It is a set of look and feels and some really good advice on how to unclutter your UI and make it pretty.  I really like it.

I am working on a Swing app in my spare time and it looks pretty nice and is very responsive.  It is not as responsive as a good native app and takes up more memory.  I think though that for this particular app I would have had a devil of a time doing it without MVC.

Sure there are hints that it isn't native if you are looking for it but honestly if this isn't good enough on modern hardware then why was a windows app okay on hardware from three years ago?

name withheld out of cowardice
Monday, June 28, 2004

The reason why I am so excited about SWT is because it allows me to use my Java skills the same way Joel uses Visual Basic: to quickly create a responsive user interface, while doing the cumbersome parts in C.

Why not Swing? I love the API and the way it was designed. I love MFC, I think it's a great idea. I know JGoodies and it rox! But at the end of the day, if I am developing a commercial app, the user is going to notice the memory hog and there's always that tenth of a second of a pause when you click a button. Users notice this, and they call if bad software, although for us programmers it's just the VM doing it's thing.

RP
Monday, June 28, 2004

Oh, and why do I want Java for that? Because I know more about Java than I do about Visual Basic.

RP
Monday, June 28, 2004

> Then again, I come from a perl background.  No fancy
> compilers pulling optimization tricks there.

No compiler maybe, but... ever used a regular expression? There's plenty of behind-the-scenes optimization going on.

Michael Eisenberg
Monday, June 28, 2004

For compiling your java app:

Excelsior JET

Okay you'll have to pay but it will work natively on Windows.

I also use JGoodies FormLayout a lot. It rocks.

And using an event loop as in SWT: no way ! (I've had my share using MFC in the past).

Swing is really cool and give it a shot in JET.

Philippe Back
Monday, June 28, 2004

So, how much does JGoodies Look cost?  I can't seem to find a price on their site.  Although, I'll admit I didn't look very hard.

muppet from madebymonkeys.net
Monday, June 28, 2004

> Then again, I come from a perl background.  No fancy compilers pulling optimization tricks there.

Of course there is a compiler. Let's not be silly. You can't execute code without a compiler somewhere. It's just that, after execution has completed, the compiler discards all of the generated parse trees, rather than saving them out to object files.

And, actually, the perl compiler does some really cool optimizations. If I remember correctly, there's a chapter in the Camel book about the perl compiler which talks in some depth about the types of optimizations that it performs.

Benji Smith
Monday, June 28, 2004

DAMN!

**climbs out from under bridge**

;)

muppet from madebymonkeys.net
Monday, June 28, 2004

I've had exactly the opposite experience: Swing feels more native than SWT.  Sure, SWT uses native widgets, but the last version I tried had the sizes all wrong, and the event handling was weird, and the performance was much worse than Swing.  (I'm sure it's improved since then.)  Really awkward things, like buttons being 3 times as tall as they should be, and clicking in the gray area of a scrollbar scrolling by 1 pixel.

I have no problem with a native toolkit, but they advertised it as "feels native everywhere!", when even their flagship application ran incredibly poorly on some platforms (mine :-).  Using native widgets doesn't *necessarily* mean it's going to feel 100% native -- you still have to take care of all the little things, and the devil is in the details, with SWT or with Swing.

Swinger
Monday, June 28, 2004

You don't happen to be this ( http://blogs.sun.com/roller/page/swinger ) Swinger, do you?
Because if you do, you've just scored a huge negative point.

Globo
Monday, June 28, 2004


JGoodies (the look and feel anyway) is free.  He sells some related stuff like (i think) some kind of form builder.

I am using jdk 1.4.2 currently which has native acceleration for Swing and to me, most actions seem pretty instantaneous.  There are exceptions.  For example, when moving a pane splitter across a paenl containing a complex set of renderers, you notice the redraw on the splitter as it moves- kinda sloppy.  Also, when dialogs pop up you often see the initial native draw of the background first.

If you haven't taken a look at Swing in a few years, give it another look.  It can be pretty zippy.

name withheld out of cowardice
Monday, June 28, 2004

I did. I've had products developed in Swing. When they were quick hacks, they worked ok. Now that we're gonna deliver them to a client, they need to be almost perfect, and that general slowness that besets Swing just won't cut it.

RP
Monday, June 28, 2004

How much of the eclipse tool was tweaked over and over again to get it as responsive as it is? I've been using it for a few weeks now and it's definitely better than the swing apps of the past, but how much work went into that?

Or does it just 'work' ?

Edward
Monday, June 28, 2004

Globo: Alas, no.  I don't blog.  I was just trying to convey the fact that I've used Swing for non-trivial projects, without realing my true identity.  Like Batman.

Swinger
Monday, June 28, 2004

One thing I never get about the love of SWT: you have to do memory management! It's not at the level of C, but if for instance you create a Color object you have to manually dispose of it. Doesn't anyone else see this as a GIGANTIC step backwards for Java?

More info:

http://cld.blog-city.com/read/15428.htm

Chris Winters
Tuesday, June 29, 2004

ew

ok no swt for me.

muppet from madebymonkeys.net
Tuesday, June 29, 2004

That's no different from Windows.Forms objects in .NET that are based on Windows handles or GDI objects. If you're using native widgets and the native environment provides only a limited pool that isn't garbage collected, all you can do is hand on the task of manual disposal to the user.

Chris Nahr
Tuesday, June 29, 2004

Yeah but .NET isn't so great, either.

muppet from madebymonkeys.net
Tuesday, June 29, 2004

So what? When you don't need the object you call a little method named "dispose()". Big deal. I once read an article on optimizing Swing apps, and it advocated(is this correct?) just that: create a destructor method where you set all your class variables to null and then call System.gc().

This was done by a team of very experienced developer at Lockheed, Boeing or Gruman, but either way, they showed it was the only way to make that particular application work in Swing.

I am sorry, but I just don't see whats the harm of calling a ".dispose()" method, when it's already a best practice to create one yourself.

RP
Tuesday, June 29, 2004

RP

That was probably a few versions of Java ago and, though I don't know the specifics, it doesn't sound like a good idea under most circumstances.  I have never heard of anyone else doing this.

Honestly I don't see where Swing would be unacceptable in terms of the speed of actually doing the work of the application.  To me, these days the only time Swing seems clunky is when doing things like dragging a window to enlarge it.  There is a very unwindows-like delay before the redraw.  Of course this was the case in Windows until a few years ago.  It is merely cosmetic though.  While I agree the Swing team should fix it so the apps don't look clunky, I don't see it as a reason to abandon Swing, given all its other advantages.

name withheld out of cowardice
Tuesday, June 29, 2004

Isn't there an implementation of the Swing API, that actually uses SWT to draw the widgets?

[break for 30 seconds to Google it]

Aha, here it is:

http://swingwt.sourceforge.net/

So, if you like the Swing API, but want native widgets, there you go.

Phillip J. Eby
Tuesday, June 29, 2004

"If you're using native widgets and the native environment provides only a limited pool that isn't garbage collected, all you can do is hand on the task of manual disposal to the user."

Why?  AWT doesn't require that; nor does wxWidgets (C++).  (I see no reason why it would necessarily be true, either -- just dealloc all the sub-widgets when a widget is deleted, an event the library can easily watch for.)

"... create a destructor method where you set all your class variables to null and then call System.gc()."

This must have been a very old JVM.  On any recent JVM, this will tend to make programs run slower, not faster.  Second-guessing a GC is hard to do, and second-guessing a non-trivial (say, generational) GC is nearly impossible.  I think some JVMs even make System.gc() a no-op.

j.g.
Tuesday, June 29, 2004

"just dealloc all the sub-widgets when a widget is deleted"

And how do you know that a widget is deleted when you don't have a deterministic destructor as in C++? (Which is why the wxWindows example does not apply.)

Note that you cannot simply delete a widget when it's no longer displayed. The client might still want to extract data, or re-display it at a later time.

Chris Nahr
Thursday, July 01, 2004

- I'm fairly certain wxWidgets doesn't use the destructor for that.

- Even if it did, that doesn't refute the AWT case.

It doesn't look like SWT really requires you to care about this very often, but that just begs the question of if they really needed this.

It seems to me that exposing this to the programmer is possibly gaining a slight speed increase, at the cost of having the programmer keep track of more things himself.  It looks like it only really comes into play with things like Fonts or Colors -- is getting a native "Font" object on Windows such a performance penalty that you need to expose this detail?  (Maybe it is -- I'm not a Windows programmer.  On Linux/Gtk+, you just use a string description of the font, almost all of the time.)

j.g.
Thursday, July 01, 2004

I have to say this: people who haven't actually used Swing and SWT for anything serious miss the point. The issue is not whether Swing is slow (its speed is fine, memory overhead is another matter), or is a better API, or looks pretty: it's that it's always done an abysmal job of mimicking the platform's look and feel.

Things that Swing in JDK 1.4 *still* gets wrong after 6 years:

* wrong basic font (why???)
* glitches in font rendering (I can provide an amusing screenshot of it's idea of what it thinks Tahoma looks like vs what other apps do)
* menus don't go away when clicking outside the app (or even on it's own titlebar)
* popups (menus, tooltips, etc) try to appear inside the Swing-owned area, leading to ridiculous behaviour of tooltips in small windows
* contents still don't resize with window by default
* still no font-selector
* All sorts of spacing and margins etc are wrong: see the sort of thing WinLAF ( http://winlaf.dev.java.net/ ) fixes.
* can't do cleartype for LCD users
* system extensions like voice input don't work in Swing's text fields

I was using Swing for a desktop app until recently, but finally gave up in disgust when JDK 1.4 not only upped the RAM reqs for the app by 2MB, but added a memory leak and removed the last sane way to get a win32 window handle for a JFrame (I use some win32 extensions).

In retrospect, expecting to be able to emulate something as complex as an OS's entire GUI layer is insane. Java doesn't attempt to emulate other platform aspects such as filesystems or network stacks, it maps to the native ones and accepts that this might occasionally expose platform-dependent behaviours.

Matthew
Monday, July 05, 2004

Finalization for operating system resources doesn't really work.  Here is an article that desribes why:

http://www.eclipse.org/articles/swt-design-2/swt-design-2.html

sammy
Friday, August 06, 2004

*  Recent Topics

*  Fog Creek Home