Diskussion:Swing (Java)

In meinen Augen ist der Artikel ungenau bzw. nicht mehr zeitgemäss. Swing ist eben nicht aus den angeführten Gründen inperformant. Wenn überhaupt, dann war Swing inperformant...mittlerweile hat Swing eine Reife erreicht, die durchaus als performant zu bezeichnen ist. Dies gilt insbesondere für Version 1.5.0. Auch wäre ein Hinweis hilfreich, dass es häufig keine Alternativen zu Swing gibt, die beiden einzigen Technologien im Enterprise - Bereich istn Dot.net und J2EE mit Swing als Frontend. SWT liesse sich auch nutzen, den Vorteilen stehen aber auch Nachteile gegenüber. Andere Technologien wie Webanwendungen lassen sich beispielsweise nicht nutzen müssen Massendaten erfasst werden oder die Applikation über umfangreiche client-seitige Funktionalität verfügen. Auch falsch: Oberfläche blockiert bei Interaktionen: hier kann ein zusätzlicher Thread die arbeitsintensive Rechenarbeit übernehmen.

Folgende Punkte sollten berücksichtigt werden: 1. Die Performance-Steigerung in Version 1.4 wurde nicht durch Nutzung nativer Komponenten des Wirtssystems erreicht, sondern durch bessere Integration der vorhandenen 2D-Bibliotheken (z.B. unter Windows DirectDraw) 2. Verliert man nicht nur unter Umständen die Plattformunabhängigkeit wenn SWT/Cocoa Verwendung finden, sondern sie ist per Definition nicht mehr vorhanden. 3. Ist die Performance der Oberflächen zumindest im Bereich SWT stark von der Implementierung der Klassenbibliothek abhängig (z. B. Windows: sehr gut, AIX: sehr schlecht) 4. Ist die Aussage "Grundsätzlich sind Swing-Anwendungen etwas langsamer als native Anwendugen" sehr gewagt, da die Performance einer Anwendung nur zu einem geringen Teil von der verwendeten Plattform abhängt (die graue Masse zwischen den Ohren alledings ...)

Die Aussagen über die Integration in das Wirtssystem sind nachvollziehbar.

IntelliJ IDE

Meines Wissens ist diese IDE nicht in Java, sondern in C++ implementiert.

Das ist nicht korrekt. IDEA ist in "reinem" Java geschrieben mit Swing-Oberfläche. --ratopi 14:24, 21. Sep 2005 (CEST)

Beispielcode

muß ich das wirklich im EDT machen? iirc ist das manipulieren von swing-objekten auch außerhalb erlaubt, solange der Frame drumrum noch nicht sichtbar ist. -- ∂ 14:17, 4. Okt 2005 (CEST)

naja, der momentane Stand scheint ungefähr der zu sein, dass die Swing-Entwickler das auch lange dachten, das mittlerweile aber nicht mehr denken: "Note: We used to say that you could create the GUI on the main thread as long as you didn't modify components that had already been realized. [PENDING: The following red text belongs in a footnote.] Realized means that the component has been painted onscreen, or is ready to be painted. The methods setVisible(true) and pack cause a window to be realized, which in turn causes the components it contains to be realized. While this worked for most applications, in certain situations it could cause problems. Out of all the demos in the Swing Tutorial, we encountered a problem only in ComponentEventDemo. In that case, sometimes when you launched the demo, it would not come up because it would deadlock when updating the text area if the text area had not yet been realized, while other times it would come up without incident.

To avoid the possibility of thread problems, we recommend that you use invokeLater to create the GUI on the event-dispatching thread for all new applications. If you have old programs that are working fine they are probably OK; however you might want to convert them when it's convenient to do so."

[[1]]

Natürlich ist das für das Beispielprogramm nicht wirklich wichtig. -- Frog 13:08, 5. Okt 2005 (CEST)

ah, vielen dank! das hatte ich noch nicht mitgekriegt, ich kannte nur den teil vor dem roten. in dem fall sollten wir's wohl im beispielprogramm drinlassen. -- ∂ 13:11, 5. Okt 2005 (CEST)

Ruf und Freunde

"Swing hatte sehr bald den Ruf, eine schlechte Performance aufzuweisen und für "ernsthafte" Anwendungen ungeeignet zu sein. Der Standard-Stil (Look&Feel) von Swing-Fenstern fand ebenfalls nicht besonders viele Freunde."

Ich würde diese beiden Sätze gerne rausnehmen und durch was objektiveres ersetzen. Für den zweiten Teil würde ich ganz gerne eine "Look-and-Feel"-Parade erstellen, also jeweils dasselbe Fenster in Metal, Motif, Windows, Mac, Ocean usw. Den ersten Satz werde ich demnächst löschen, wenns da nicht größere Einwände gibt. Wer mag, soll statt dessen was über die Vor- und Nachteile von Heavyweight/Lightweight-Komponenten schreiben. -- Frog 15:15, 11. Okt 2005 (CEST)

Swing vs. SWT

Warum ist nur SWT Hauptkonkurrent? Was ist mit Web-Anwendungen? Wann ist eine Lösung der anderen vorzuziehen? --Michael Hüttermann 10:32, 27. Feb 2006 (CET)

Ich halte die Aussage "Konkurrent" für sehr ungenau und eigentlich falsch. Es wird zwar von vielen als Konkurrenz angesehen, hat sich aber eher als eine technologische Alternative entwickelt (in meinen Augen keine wirklich gute...). So wie auch reine AWT-Anwendungen eine technologische Alternative zu Swing-Anwendungen sind (ja, ich weiß, dass Swing auf AWT basiert...).

Ob man jetzt JSF/JSP und Webanwendungen im allgemeinen nun auch als Konkurrenz betrachten soll, möchte ich bezweifeln. Zwar könnte man Swing mittels eines JSF-Renderes abbilden, aber Webanwendungen sind auch jetzt im Anbruch des Web 2.0 Zeitalters immer noch klassische Server-Anwendungen mit einem Terminal-Frontend (jetzt heißt es ja Browser). Swing-, SWT-, AWT- und die ganzen Nicht-Java-Anwendungen-GUI-Frontends (wx, tk usw.) sind eher im Desktop, d.h. Rich-Client Bereich zu sehen.

Ich würde die Aussage Hauptkonkurrent komplett streichen. --Arittner 12:08, 27. Feb 2006 (CET)

seh ich genauso! sorry wenn das falsch rüberkam. ich habe den Artikel diesbezüglich geändert da steht nämlich swt ist konkurrent von swing. meine Modifikation im Artikel war dass beides keine Konkurrenten sind sondern komplementär eingesetzt werden - beides hat Vor- und Nachteile. Das fehlt in meinen Augen. Leider wurde dieser Beitrag wieder entfernt......  :-( --Michael Hüttermann 13:19, 27. Feb 2006 (CET)