Zum Inhalt springen

Diskussion:Swing (Java)

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 4. Dezember 2006 um 14:54 Uhr durch Brf (Diskussion | Beiträge) (lightweight = all-Java language). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 19 Jahren von Michael Hüttermann in Abschnitt Artikel umschreiben

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)

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)

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) jpp ?! 18:18, 14. Apr 2006 (CEST))

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)Beantworten
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)Beantworten
Ach so, ich dachte...--Michael Hüttermann 20:44, 10. Mai 2006 (CEST)Beantworten

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