2

What are the major differences which may be encountered? Any major differences in application design? Threading models? The way you go about constructing GUIs? Any features of SWT which aren't available in Swing?

akatkinson
  • 548
  • 4
  • 17

1 Answers1

5

Few findings from my experience between Swing and SWT

  • Rendering of Swing is a bit slower (my experience) and use much more memory
  • Native look is possible just partially (depends on selected look'n'feel)
  • Most of Swing components somehow implements MVC pattern (so you don't have to make your own data binding)
  • It's possible to subclass components and it is used when you have to change behaviour of some component (so it's used often)
  • Swing sends program generated events (I hate this behavior ;] )
  • In Swing you don't have to call (a)syncExec() method (you don't have to care from which thread you are updating your GUI so much as in SWT, but be sure to read Swing threading policy (end of page) and Concurrency in Swing)
  • Swing is really garrulous (compared to SWT)
  • No more dispose() methods ;]
  • Swing have standard layout manager in containers (see BorderLayout) and have different layout managers in basis (use MigLayout, it's for Swing and SWT as well and have no competitor)
  • You don't have to know your parent on component instance creation, but you'll have to you .add(Component c) method on parent (container)
  • Swing is not platform dependent (no more multi-builds for each platform and x32/x64)
  • Swing have its own bugs (as other technologies, it's inevitable)
Sorceror
  • 4,835
  • 2
  • 21
  • 35
  • 1
    Swing components are **not** thread safe. All GUI updates should be done from the Event Dispatch Thread. – Jonas Jul 12 '11 at 08:22
  • Just to add that Swing has more components an is much more customizable than SWT(you can make prettier GUI's). – Zemzela Jul 12 '11 at 08:30
  • @Zemzela it depends on opinion, I believe (as experiences SWT and Swing programmer) that both GUI frameworks have same expression possibilities.. But it's right that make own component in SWT is little bit harder (more work, more code), but in SWT you don't do this a lot.. – Sorceror Jul 12 '11 at 08:36
  • that isn't true 1) Rendering of Swing is a bit slower (my experience) and use much more memory == wrong advice 2) Swing is not single threaded UI as SWT == wrong advice, Swing is only and only single threaded for output to the GUI 3) Swing is really garrulous == ???? 4) No more dispose() == wrong advice, dispose <> finalize – mKorbel Jul 12 '11 at 10:44
  • @mKordel 1) memory blueprint is much higher than SWT have, it can be proofed, anyway, rendering speed is my opinion (as all those findings, as I wrote) 2) again, I'm not sure how to write this idea correctly, but in Swing, you don't have to call `display.syncExec(Runnable thread)` (or I'm not really aware of any necessary usage). I'm open for any more correct description 3) Means you have to write much more code than in SWT, cause Swing does not use bit setting as SWT (SWT.CLOSE | SWT.OK | SWT.CANCEL, etc..). – Sorceror Jul 12 '11 at 11:25
  • @mKordel 4) Definitely dispose != finalize, but i didn't said that, again I'm no aware of disposing any component of Swing, in SWT you have to dispose Font, Colors, etc.. – Sorceror Jul 12 '11 at 11:26