Swing wird nicht weiterentwickelt?

[Silencer54]

Habe gehört dass Swing nicht weiterentwickelt werden soll da es in der Synchronisation von Threads nicht sicher ist und es andere Probleme geben soll.
Bin eigentlich bisher immer gut mit Swing gefahren und wollt mal wissen ob jemand von euch das Gerücht bestätigen kann bzw eure Meinungen zu Alternativen wie SWT.

Falls der Fred doch ins SpecForum sollte SRY und bitte verschieb.

[Shink]

Wer hat denn das gesagt? AFAIK gibts doch z.B. in 1.6 wieder einige Neuerungen.
Ich bin eigentlich auch meistens gut gefahren mit Swing.

[Senior Sanchez]

...da es in der Synchronisation von Threads nicht sicher ist und es andere Probleme geben soll.

Die Probleme gab es doch schon immer ;) Die Synchronisationssache ist nichts Neues und wenn man sich dort an bestimmte Regeln hält, dann klappt das eigentlich auch.
Die anderen Probleme (welche meinst du jetzt genau?) sind denke ich kein Grund die Entwicklung abzubrechen. Nichts ist fehlerfrei und bisher hat man es ja meistens doch irgendwo hinbekommen, wenn es mal gehakt hat.

mfg Senior Sanchez

[Shink]

Sollte sich tatsächlich Swing nicht mehr weiterentwickeln, wär das auch kein Weltuntergang, da ja Swing auf AWT aufsetzt und bei AWT gibts ja mit jedem Release massive Verbesserungen (v.a. Performance). Mit 1.6 z.B. sollte die Direct3D-Beschleunigung um einiges an Performance zulegen.

[Silencer54]

Meinte probleme mit darstellung von Bordern und kompatibilität mit ati Grakas.
Wobei das nur Erfahrungsberichte von Dritten waren und ich selber noch keine Probleme hatte daher hab ich mich eben gewundert und wollt wissen obs da konkretere Hinweise auf die Weiterentwicklung gibt (Was ja nicht der Fall zu sein scheint).

[HellHorse]

Habe gehört dass Swing nicht weiterentwickelt werden soll
Das ist kompletter Bullshit. Das Gegenteil trifft zu, mit 1.6 wird Swing kräftig weiterentwickelt.
Siehe dazu:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/index.html#Swing


da es in der Synchronisation von Threads nicht sicher ist
a) sind das die meisten anderen Toolkits auch (inkl SWT)
b) ist das Absicht, Swing-Komponenten nur im event-dispatch-Thread erzeugen/bearbeiten und gut ist


bzw eure Meinungen zu Alternativen wie SWT.
siehe dazu
http://www.hacknot.info/hacknot/action/showEntry?eid=74 (im Moment unten)
Macht ein paar sehr gute Punkte, allerdings lässt er auch ein paar negative Punkte von Swing aus.
Ich habe keine definitive Antwort und entscheide mich von Fall zu Fall ob Swing oder SWT. Swing und SWT gegeneinander abzuwägen ist recht kompliziert und endet of in Flamewars.
Allerdings kann ich sagen falls Swing, dann gutes LAF und JDIC.

[Silencer54]

@HellHorse

Da du offensichtlich schon mit beiden (Swing und Swt) bzw auch anderen Toolkits gearbeitet hast, könntest (wennst Lust und Zeit hast )doch die Grundsätzlichen Vor- und Nachteile von Swing, Swt und anderen Toolkits aufzeigen. Nicht um nen War anzuzetteln sondern um einfach nen Überblick über die Möglichkeiten der einzelnen Toolkits zu bekommen, da diese oft in Büchern nicht wirklich klar werden.
Meiner Meinung nach sind Leute die daraus nen Flamewar machen eh nur Kinder (es geht schließlich darum dazu zu lernen und Situationsbedingt gute Programme zu schreiben)

[Senior Sanchez]

Sollte sich tatsächlich Swing nicht mehr weiterentwickeln, wär das auch kein Weltuntergang, da ja Swing auf AWT aufsetzt und bei AWT gibts ja mit jedem Release massive Verbesserungen (v.a. Performance). Mit 1.6 z.B. sollte die Direct3D-Beschleunigung um einiges an Performance zulegen.

Ehm, also ich will Swing nicht mehr missen, weil Swing doch deutlich leistungsfähiger ist, um anspruchsvolle GUIs zu bauen.


mfg Senior Sanchez

[stefan42]

SWT gegen Swing:
* SWT verwendet (zumindest teilweise) native Widgets (Buttons, Selectboxen), dadurch oftmals besseres Look and Feel. Swing zeichnet alles per Java2D und das sieht je nach Look And Feel furchtbar bis ganz nett aus.
* SWT ist unter Windows schnell (wird oft als schneller als Swing wahrgenommen)
* SWT ist unter Linux z.T. sehr lahm (Eclipse 3.1 und neuere GTK 2 Versionen scheinen aber das zu verbessern)
* Swing wird immer schneller. Insbesondere die 1.6 Builds lassen einiges erhoffen.
* SWT ist von der Programmierung her weniger elegant als Swing und erinnert z.T. an die MFC. (z.B. alle (?) Konstantendefinitionen in der Klasse SWT, oftmals kein Subclassing erlaubt, kein gemeinsames Interface für die unterschiedlichen Betriebssysteme (!) sondern separate Klassen). Wenn man also Flexibilität braucht (in anderen Worten: Ein Widget, das es in Eclipse nicht gibt), dann kann das per SWT sehr schwer bis unmöglich werden. Mit Swing ist so gut wie alles möglich. Die Programmierung ist immer sehr objektorientiert, wenn auch z.T. komplex (Textwidgets mit styled Documents etc.)
* Vom Speicherverbrauch sehe ich keinen Unterschied. Manche behaupten, dass SWT etwas weniger bräuchte.

Kann gerne ergänzt / berichtigt werden!

Viele Grüße,
Stefan

[Shink]

@Senior Sanchez: Ich auch nicht, das meinte ich auch nicht. Ich meinte: wenn Swing so bleibt, wie es ist, werden Swing-basierte Anwendungen trotzdem schneller und vermutlich auch schöner, da ja Swing (AFAIK) ausschließlich AWT-Klassen/Methoden verwendet und nichts natives drin ist.

[HellHorse]

Dann muss ich woh auch mal ;)

Swing vs SWT nach Runden, kein Anspruch auf Vollständigkeit

MVC
Swing wurde von Anfang an auf darauf ausgelegt und ist daher gut integriert. Bei SWT ist es angeflanscht und weniger intuitiv. Dafür bietet es direkt filtering und sorting support (kommt bei Swing noch).

3rd party support (widgets, layouts, lafs, charts, ....):
klarerer Vorteil Swing

Dokumentation:
klarer Vorteil Swing

Speicherverbrauch:
Bei keinem so, dass es bei einem durchschnittlichen Desktoprechner is Gewicht fallen würde.

Geschwindigkeit:
Unter Windows gut bei beiden. (Java 1.5 und ~1GHz, >= 256 MB)
SWT-GTK eher lahm, aber nicht wirklich langsamer als z.B. Firefox.
SWT-Motiv schnell.
Swing unter Linux mit NVIDIA Grafikkarte gut.

Layout:
Bei beiden gleich. SWT kennt bloss preferredSize was es etwas kompilzierter macht.
Für Swing gibt es aber viele LayoutManager im Internet.

GUI-Builder:
:wayne:

Event-handling/synchronisation:
Bei beiden gleich

Flexibilität:
klarer Vorteil Swing

Desktopintegration:
Vorteil SWT. Wenn man allerdings JDIC verwendet, hat man praktisch einen Gleichstand. In beiden Fällen nicht perfekt.

Stabilität:
Klarer Vorteil Swing, was allerding auch daran liegt, dass sich ein den letzten Jahren nicht allzuviel getan hat.
SWT ist doch noch stark in Entwicklung (Spinner kamen er vor Kurzen) und ändert sich doch recht stark.
So ist z.B. Azureus schon zum zweiten mal im 3.1er Zyklus gebrochen und falls sich niemand überwindet und Veronika belästigt wird es wohl mit 3.1 final nicht laufen. GridLayout wurde vor Kurzen neu geschrieben, da es zu viele Bugs hatte.
Allerdings hat Swing auch ein paar alte Bugs(/RFEs) die nicht oder erst jetzt gefixt werden.

"Plattformunabhänigkeit":
Obwohl SWT eigentlich nicht portabel ist, ist es für mehr Plattformen verfügbar. Darunter diverse "obskure" Unices (wenn auch nur Motiv) und auf PocketPC. Dafür gibt es im Gegensatz zu Swing noch keine Win64 Version.
Zudem lassen sich bei Swing Sachen wie Fokus Management plattformunabhänig und -übergreiffend kontrollieren.

Lizenz:
SWT is open source und arbeitet problemlos mit freien Java Implementationen wie gcj und classpaht zusammen. Swing nicht.

2d Grafik:
klarer Vorteil Swing

Widgets:
Einerseits bietet SWT eine Menge fortgeschrittener Widgets (das meiste custom, also emulitert) darunter Banner, CoolBar, TreeColumn, CTabFolder allerdings fehlt auch manches wie JLayeredPane, JDesktopPane und für Listen gibt es bloss ein Layout.
Allerdings gibt es für Swing viele Widgets im Netz.

LAF:
Der wohl strittigste Punk. Grösste Chance auf Flamewars.
- Metal ist scheisse, aber es gibt diverse sehr schöne Swing LAFs für kein oder wenig Geld
- SWT-Motiv ist grössere Scheisse
- vieles an SWT ist nicht nativ darunter all das fortgeschrittene Zeugs in custom und Eclipse Forms
- natives Look and Feel umfasst sehr viel mehr als Widgets sondern auch Layout, Borders, Icons, Anordnung (Reihenfolge von "Ok" und "Cancel"), Abstände,.... Wers nicht glaubt schaue sich mal einen Eclipse Wizzard unter Linux an. Das ist ganz klar Windows Look and Feel.
- ein gutes LAF macht noch kein gutes GUI
- das Windows LAF von Swing hat ein paar Probleme (vieles davon wurde schon in den 1.6 alphas gefixt). Wer es schon jetzt besser will nimmt WinLAF (https://winlaf.dev.java.net/). Für MacOS gibt es Quaqua (http://www.randelshofer.ch/quaqua/download.html). Aber auch SWT ist nicht perfekt: http://bugs.eclipse.org/bugs/show_bug.cgi?id=24538
- das GTK LAF von Swing unterstüzt nur wenige engines (auch das soll sich mit 1.6 ändern)

unkategorisiert:
- SWT hat Eclipse Forms
- SWT erlaubt mehr Kontrolle über Fenster und nicht-reckige Fenster
- SWT hat ein Problem mit PNG-24 und Transparenz
- #computeSize von Label (SWT) kann u.U etwas falsches zurückgeben -> Pferdchen durfe deswegen schon extra einen LayoutManager schreiben
- SWT wurde mit der Einstelllung "Swing ist scheisse" entwickelt, die findet man immer noch in der Mailingliste. Daher verwendet man gar kein AWT und hat z.B eigene Klassen für Point und Rectangle.
- trotzdem lässt sich AWT in SWT integrieren, wenn auch etwas buggy
- SWT wurde/wird für Eclipse entwickelt, was hauptsächlich für Windows entwickelt wird. Hin und wieder wird eine API ausgreissen (SWT, JFace, Forms, AST, Compiler, ...).

sightings:
http://java.sun.com/products/jfc/tsc/sightings/
http://www.oneclipse.com/Members/admin/news/swt-sightings


* SWT verwendet (zumindest teilweise) native Widgets (Buttons, Selectboxen),
Genau, manchmal und machmal nicht. Manches wird emuliert, manches ist bloss hint und wird weggelassen. Manchmal macht man auch grössten gemeinamen Nenner wie AWT (obwohl man AWT das natürlich vorwirft ;)).

dadurch oftmals besseres Look and Feel.
Warum? Bloss weils nativ ist? Dann wäre ja Eclipse Forms und org.eclipse.swt.custom alles crap? Ja, Metal sieht scheisse aus, aber es gibt sehr viele sehr gute LAFs für Swing die weniger als ein Enwicklerlohn pro Tag kosten.


Swing zeichnet alles per Java2D
Nicht wirklich


und das sieht je nach Look And Feel furchtbar bis ganz nett aus.
Dann nimm halt ein anders LAF, ich sehe hier wiklich das Problem nicht. Zudem ist in den 1.6ern schon einiges gefixt (M von "My Documents" z.B.).


* SWT ist unter Windows schnell (wird oft als schneller als Swing wahrgenommen)
IMHO gibt es auch an Swing unter Windows nichts auszusetzen. Swing läuft genauso wie SWT am besten auf Windwos.


* SWT ist unter Linux z.T. sehr lahm
Stimmt für GTK2 (soll laut Mailinliste daran liegen, dass GTK das Konzept des Z-index nicht kennt), nicht für Motiv. Viel schlimmer ist allerdings, dass die GTK2 Version kein Drucken unterstützt!


erinnert z.T. an die MFC.
Die Windows API war das Ziel von SWT.


alle (?) Konstantendefinitionen in der Klasse SWT
Eben nicht ganz.


oftmals kein Subclassing erlaubt
Bloss Canvas und Composite "darf" man subclassen. Die anderen kann man zwar, wenn man die richtige Methode überschreibt, aber es wird keine Grantie übernommen, dass es in der nächsten Version auch noch läuft.

lustige Annektote am Rande:
Es gibt sowohl Swing via SWT (http://swingwt.sourceforge.net/) als auch SWT via Swing (http://chrriis.brainlex.com/projects/swtswing/).

Fazit:
Ich werde mich davor hüten, eines davon als besser hinzustellen. Zumal ich einen Haufen ausgelassen/vergessen habe.

Fazit zu SWT:
Stark in Entwicklung.
Hat dank Eclipse starken Rückenwind.

Fazit zu Swing:
Auch wenn es mache Sachen nicht out-of-the-box bietet, so ist es mit hoher Wahrscheinlichkeit im Internet für kein ober wenig Geld verfügbar.
In letzer Zeit tat sich recht wenig, was sich mit 1.6 zum Glück ändert.

Mein persönlicher Vorschlag:
Swing lernen (da besser dokumentiert), dann SWT anschauen (da viel Wissen übernommen werden kann) und sich selbst eine Meinung bilden.

[Senior Sanchez]

* SWT ist unter Windows schnell (wird oft als schneller als Swing wahrgenommen)

Sone Aussage ist mit Vorsicht zu genießen. Swing-GUIs können auch zackig sein, man muss nur wissen wie man es anstellt ;) Gerade das aufbauen einer GUI lässt sich bei Swing rapide durch den Einsatz von Threads beschleunigen, die den Teil der GUI im Hintergrund zusammen basteln, der noch nicht benötigt wird. Natürlich schön den Dispatch-Thread nutzen ;)

Und wenn ich mir mal sowas wie den JBuilder anschaue (gut der 2005 is recht lahm, aber die davor) können Swing-GUIs auch schnell in großen Projekten sein und ich weiß da nicht ob dort Eclipse oder der JBuilder zügiger ist.


mfg Senior Sanchez

[Shink]

Stimmt; vor allem der JBuilder 9 ist sehr fix selbst auf langsameren Rechnern.
Beim 2005er Personal kann man auch noch einiges rausholen, wenn man ihn die JRE 1.5 verwenden lässt (und nicht die mitgelieferte 1.4.2). Dann geht auch Font-AA und eventuell sogar OpenGL-Beschleunigung. Die Umstellung ist allerdings nicht grad intuitiv wenn man sich nicht auskennt.

[Senior Sanchez]

Stimmt; vor allem der JBuilder 9 ist sehr fix selbst auf langsameren Rechnern.
Beim 2005er Personal kann man auch noch einiges rausholen, wenn man ihn die JRE 1.5 verwenden lässt (und nicht die mitgelieferte 1.4.2). Dann geht auch Font-AA und eventuell sogar OpenGL-Beschleunigung. Die Umstellung ist allerdings nicht grad intuitiv wenn man sich nicht auskennt.

Kannste mal kurz ne Anleitung geben, wie ich das umstelle? Ich blicke da beim JBuilder immer nicht bei den haufen Config-Files durch *g*


mfg Senior Sanchez

[Shink]

Das ist nicht so einfach:
Soweit ich mich erinnern kann beschränken sich die Veränderungen auf die Datei JBuilder2005/bin/jdk.config
Hier ersetzen wir natürlich in der Zeile "javahome ../jdk1.4/" das Verzeichnis mit dem Verzeichnis, wo unsere JDK1.5 drin ist. (Ob es mit 1.6 geht, muss ich erst testen...)
Das selbe gilt für "addpath ../jdk1.4/lib/tools.jar".
Allerdings brauchen wir noch die Apache Crimson-Packages, die im JRE1.5 jetzt unter einem anderen Pfad sind. Ich hab das (GLAUB ICH) so gelöst, dass ich "rt.jar" vom JRE1.4 entpackt hab, das Verzeichnis "org/apache/crimson" unter Beihaltung der Verzeichnisstruktur in eine JAR gepackt habe und diese dann mit addpath hinzugefügt habe.
Möglicherweise funktionieren nicht mehr alle Themes vollständig (vor allem beim "Windows"-Theme kanns Probleme geben, "Windows Classic" funktioniert hingegen)

[Shink]

Nachtrag: JBuilder 2005 mit JDK1.6 funzt nicht bei mir