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)