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)

Reine Formsache, ich weiß, aber ist es nich üblich, zu schreiben "public static void main (String[] args)" - also "args" und nicht "arg"...? --80.136.190.14 16:33, 16. Nov. 2007 (CET)

Du hast recht. Ich habe den Artikel entsprechend abgeändert. --Stefan Birkner 23:24, 16. Nov. 2007 (CET)

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)

mehr als "es gibt genau eine wichtige alternative, und die heißt SWT" gibt es dazu imho nicht zu sagen. natürlich konkurrieren swing und SWT - schließlich erfüllen sie bei licht betrachtet den selben zweck. was du mit "komplementär eingesetzt" meinst ist mir überhaupt nicht klar - ich will eine GUI, es soll auf allen wichtigen OS laufen - da habe ich die wahl, aber im endeffekt ist es gehupft wie gesprungen was ich nehme. -- ∂ 14:55, 27. Feb 2006 (CET)

naja, das ist aber auch nur ganz oberflächlig so. --Michael Hüttermann 15:52, 27. Feb 2006 (CET)

unverständlicher Satz

Den folgenden Satz verstehe ich nicht: „Gerade weil Swing sehr flexibel ist, kann es bei der Realisierung von eigenen "cutting edge" Komponenten zu einem Verlust der Plattformunabhängigkeit kommen.“ Was ist denn bitteschön eine cutting edge Komponente? Und warum kann sie zu einem Verlust der Plattformunabhängigkeit führen? Erleuchtet mich bitte. --jpp ?! 14:47, 27. Mär 2006 (CEST)

Das bedeutet, dass die Plattformunabhängigkeit zwar theoretisch vorhanden ist. Wenn Du allerdings eigene (visuelle) Komponenten schreibst oder bestehende sehr umfangreich modifizierst oder erweiterst geht die Plattformunabhängigkeit sehr schnell flöten. Eine cutting edge-Komponente ist eine Komponete, die die Flexibilität von Swing voll ausnutzt, eine grenzwertige Komponente mit mächtiger Funktionalität und/oder einer pfiffigen technischen Lösung für eine bestimmte Aufgabenstellung. --Michael Hüttermann 17:32, 29. Mär 2006 (CEST)

Versteh ich leider immer noch nicht. Warum geht die Plattformunabhängigkeit flöten, wenn ich eigene visuelle Komponenten schreibe? Ich verwende doch keine nativen Funktionen. Der Begriff „Cutting-Edge-Komponente“ ist m. E. nicht sehr verbreitet und sollte daher im Artikel erklärt oder verlinkt werden. --jpp ?! 19:46, 29. Mär 2006 (CEST)

Sorry, wenn ich mich etwas unklar ausdrücke. Ein Beispiel, dass die Plattformunabhängig leidet wäre: Du musst einer Komponente ein eigenes, neues UI zuweisen. Dazu leitest Du gewöhnlich von einer Basis UI-Klasse ab. Diese Basisklasse ist allerdings in der Regel eine plattformabhängige Klasse. Du könntest mit sehr grossem Aufwand die Plattformunabhängigkeit Deiner Komponente wiederherstellen, allerdings ist das sehr kostenintensiv und meist einfach garnicht nötig, da die Anwendungen per se auf einer Zielplatform laufen (zumindest bei betriebswirtschaftlichen Anwendungen). Und das kommt häufiger vor wenn die visuellen Komponenten ein Verhalten haben sollen welches deutlich über dem Swing Standardverhalten hinaus gehen, also cutting edge sind. Ich hoffe, dass ist jetzt deutlicher geworden. Wenn man das jeden Tag macht hapert es manchmal an einer plausiblen, einfachen Erläuterung (Tunnelblick). Bei Cutting edge gebe ich Dir Recht. Im Englischen gibt es Cutting edge bereits als Worterklärung. Fehlt noch. --Michael Hüttermann 21:33, 30. Mär 2006 (CEST)

Ähm... ich nerve bestimmt, aber:

1. Wir sollten zuerst einmal klären, was du mit „Plattform“ meinst. Wohl kaum das Betriebssystem, denn ComponentUI und dessen Derivate sind keine nativen Klassen. Es gibt sie aber für verschiedene Look-and-Feels. Kann es sein, dass du eigentlich darauf hinauswillst, dass das Ableiten von UI-Klassen in eine Abhängigkeit von bestimmten Look-and-Feels führt? Dann ist der Begriff Plattform unpräzise.
2. Die korrekte Schreibweise wäre „Cuttin-Edge-Komponente“. Siehe auch Durchkopplung.

--jpp ?! 20:01, 31. Mär 2006 (CEST)

Plattform kann auch OS bedeuten, aber nicht nur. Selbstverständlich ist ComponentUI nicht native...wer hat das behauptet? Durchkopplung gut und schön kannste gerne anpassen....du hast allerdings ein g vergessen, es heisst cutting. --Michael Hüttermann 21:59, 1. Apr 2006 (CEST)

„g“ vergessen – stimmt. :-) Sofern du mit Plattform nicht OS meinst, hat niemand native behauptet. Ich wollte nur sichergehen, eben weil Plattform so ein schwammiger Begriff ist. --jpp ?! 00:31, 2. Apr 2006 (CEST)

Deine Ergänzung gefällt mir sehr gut, super! Jetzt ist es noch klarer was gemeint ist. --Michael Hüttermann 20:16, 3. Apr 2006 (CEST)

Michael Hüttermann schrieb: "... das kommt häufiger vor wenn die visuellen Komponenten ein Verhalten haben sollen welches deutlich über dem Swing Standardverhalten hinaus gehen, also cutting edge sind ..." – Das mag eine interessante Info sein, allerdings, wenn ich es richtig verstehe, soll dieser Artikel Swing erklären, aber nicht selbstgeschriebene über Swing hinausgehende Komponenten. Das wäre, glaube ich, so, als wenn man die Hitze der Sahara beschriebe, aber hinzufügte, sie könne jedoch, wenn sie "cutting-edge" am Nordpol läge, auch sehr kalt sein. --Suaheli 00:06, 7. Okt. 2008 (CEST)

Artikel umschreiben

Die bisherigen Diskussionspunkte kann ich nachvollziehen.

Vorallem die Look-and-Feel Parade (Ocean, Windows, Gtk, Mac, Motif und dann noch zum Vergleich AWT und SWT auf verschiedenen Plattformen) würde ich auch begrüssen. Vielleicht sollte man dafür einen Unterartikel bilden, die die Vergleiche sicherlich ziemlich umfassend werden. Damit die Vergleiche auch etwas taugen, sollte man vielleicht auch Screenshots von verschiedenen Standardkomponenten (File-Dialog, ...) machen.

Dafür würde ich einen neuen Artikel "Aussehen von Java-Oberflächen" oder sowas in der Art erstellen.

Vielleicht könnte man auch einen Vergleich zwischen den Look and Feels für verschiedene Versionen machen (ab Java 6 wieder natives Rendering, aber keine nativen Widgets). (nicht signierter Beitrag von 83.78.155.75 (Diskussion) )

hallo jpp. Das finde ich eine sehr gute Idee! L&F und der Vergleich bzw. Abgrenzung/Abhängigkeit zu AWT und SWT sind sehr sinnvoll, fehlen noch total. Das ganze anreichern mit Screenshots...wunderbar! Eine Verfassung unter dem Deckmantel "Java-Oberflächen" gefällt mir gut. Da kann man dann auch JFC mit einbringen, was ja schon mit Swing und AWT angesprochen wurde. Auch die Unterschiede mit Java Mustang gehört dann da mit rein. Wenn Du damit loslegen möchtest....ich würde mich dann da auch gerne inhaltlich beteiligen. --Michael Hüttermann 18:24, 10. Mai 2006 (CEST)

Schmück mich nicht mit fremden Loorbeeren. Der Vorschlag kam von Benutzer:83.78.155.75. Ich habe nur die Signatur nachgetragen. --jpp ?! 20:04, 10. Mai 2006 (CEST)

Ach so, ich dachte...--Michael Hüttermann 20:44, 10. Mai 2006 (CEST)

lightweight = all-Java language

Die Definition lightweight = all-Java language

stammt aus

http://java.sun.com/j2se/1.5.0/docs/api/overview-summary.html

und http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/package-summary.html

Total aufgeblasenes Hallo Welt-Beispiel

Hallo,

Hallo Welt-Beispiele sollen eigentlich nicht so viel Features wie möglich auf engsten Raum packen, sondern ein für die Sprache kurzmöglichstes Beispiel einer einfachen Ausgabe (...) sein (meine persönliche Interpretation). Hier werden völlig unnötige Sachen erledigt (LAF wechseln, GUI-Aufbau im Swing-Thread planen, ...), die das ganze völlig aufblasen und meines Erachtens fürchterlich abschrecken. Spricht irgendetwas dagegen, das zu entfernen? --Benji 18:15, 1. Jul. 2007 (CEST)

Nein, ich stimme mit dir überein. --Stefan Birkner 11:47, 2. Jul. 2007 (CEST)

Okay, ich habs dann mal gekürzt. --Benji 21:25, 2. Jul. 2007 (CEST)

Beispielprogramm: Objekt zum JFrame hinzufügen

Hallo,

der Revert ist unnötig. Mein "funktioniert so nicht" nehme ich zurück. Ich hatte die falsche Erinnerung im Kopf, der Beispielcode würde so nicht kompilieren. Muss ich verwechselt haben. Aber das zweite gilt nach wie vor: getContentPane() veraltet, add() ist völlig ausreichend. Hier steht unter der Überschrift "Mit add() auf den Container":
"Das Programm erzeugt ein JLabel-Objekt und setzt es mit add() auf den JFrame. Der JFrame verwaltet einen der Container mit dem Namen »Content-Pane«, der das Swing-Objekt aufnimmt. Vor Java 5 konnte nicht direkt mit add() gearbeitet werden, da der JFrame genau genommen nicht nur einen Container verwaltet, sondern viele, und wir mussten uns den Content-Pane mit getContentPane() erfragen und dann add() auf diesem Container-Objekt ausführen:

Container con = frame.getContentPane();
con.add( component );

-- ri st 17:30, 15. Jul. 2007 (CEST)

Dass add() alleine funktioniert ist klar, doch woher nimmst du die Aussage, dass getContentPane() veraltet ist. --Stefan Birkner 17:42, 15. Jul. 2007 (CEST)

Das frag ich mich auch. Ich kann meine Swing-Programme, die selbstverständlich, wie es bei Swing seit jeher üblich war, in JFrames per getContentPane().add() arbeiteten, genauso in Java 1.5 oder sogar Java 1.6 benutzen. Daraus schließe ich, ohne nachzuschauen, dass das ganze kompatibel blieb, und damit brauch das Beispiel auch nicht verändert werden. --Benji 20:29, 15. Jul. 2007 (CEST)

Es muss nicht verändert werden, weil es immer noch läuft. Ich frage mich aber, ob wir es nicht dennoch verändern sollten weil die neue Form (ohne getContentPane) einfacher ist. Und Code-Beispiele sollten m. E. immer so einfach wie möglich sein. --jpp ?! 11:06, 16. Jul. 2007 (CEST)

Stimmt, aber nicht jeder hat zwangsläufig die neuste beste tollste Java-Installation drauf und kann dann das Sourcecodebeispiel nicht nachvollziehen, was in seiner jetzigen Form selbst mit einer 10 Jahre alten Java-Installation (seit Java 1.2 gabs glaub ich Swing, siehe Artikel ;) ) noch möglich ist. Aus den Gründen wäre ich daher für behalten. --84.178.33.24 14:32, 21. Jul. 2007 (CEST) (IP aka Benutzer:Benji)

„Java2D“ / „Graphics2D“

Wie auch immer sie heißen mögen, meines Erachtens ist weder „Java2D“ noch „Graphics2D“ der Swing-Komponente zu verdanken, sie müssten also gestrichen werden in der Features-Aufzählung. Ich denke, die besagten 2D-Klassen sind völlig unabhängig von Swing. - java.awt.Graphics2D basiert jedenfalls direkt auf java.awt.Graphics. --Suaheli 04:40, 14. Okt. 2008 (CEST)

Sie heißen wohl Java 2D. „Graphics2D“ ist mir unbekannt. Heutzutage hat diese API nichts mit Swing zu tun. Könnte sein, dass das historisch mal gemeinsam entstanden ist, das kann ich aber weder be- noch widerlegen. Fazit: Sollte entfernt werden. --j ?! 13:56, 14. Okt. 2008 (CEST)

Separation of Concerns

Separation of Concerns allerdings wird von Swing nicht grade unterstützt. Swing ist darauf ausgelegt, die Geschäftslogik und das GUI zu vermischen. Controls benutzen eigene "proprietäre" Interfaces für die angezeigten Daten, die seitens des Datenmodells implementiert werden müssen, will man nicht eigene GUI-Daten-Objekte einführen, die dann die Daten-Entities duplizieren. Besser wäre es, wenn das GUI bestehende Daten-Objekte anzeigen und manipulieren könnte, ohne dass diese Datenobjekte Darstellungs-/Swing-Klassen bzw. -Interfaces importieren müssen.

Ich schreibe das hierhin und nicht auf die Artikelseite, weil ich grad keine Belege liefern kann und weil mir hier bestimmt jemand widerspricht... oder? Kruemelmo 15:16, 5. Nov. 2009 (CET)

Das geht alles ich weiss nicht wo dein Problem ist. Deine Datenobjekte bekommen entsprechende Methoden die die Daten liefern und die Swingkomponente zeigt sie an, das kann man dann noch mit Oberservern automatisch machen. Sobald sich Daten im Model ändern werden sie in der GUI aktualisiert. Man kann sich auch Beans bauen die einer "echten" Komponente entsprechen wie in Delphi.

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.tutego.com/java/articles/Swing-thread-sicher.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.tutego.com/java/articles/Swing-thread-sicher.html

– GiftBot (Diskussion) 13:40, 27. Nov. 2015 (CET)