# AWT, Swing & was sonst noch.



## Corcovado (20. Apr 2005)

Hallo,
Mich wuerde mal interessieren worin die Unterschiede der untersch. Grafikbuechereien bestehn - Ich hab etwas mit Swing gearbeitet und denke, das Swing einfacher zu handhaben ist, andererseits bin ich auch immer wieder auf Klassen gestossen, von denen es heisst, sie waeren in zukuenftigen Swing versionen wahrscheinlich nicht mehr, oder nicht mehr in der Form enthalten?! AWT machte fuer mich immer eher einen etwas "urigeren" Eindruck. Schwerer zu bedienen bzw man hat einen groesseren Aufwand damit, aber wie sieht es da mit "zukuenftigeren Versionen" ? Ist AWT quasi zeitloser als Swing? Wie ist das mit Geschwindigkeit und Performance?

AWT, Swing was sind die Vorteile und was die Nachteile? Was gibt es ausserdem noch?


----------



## Illuvatar (20. Apr 2005)

Swing sieht besser aus und kann mehr, is aber noch nen Tick langsamer


----------



## Roar (20. Apr 2005)

du meinst wohl das hier:



> Warning:  Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM  has been added to the java.beans package. Please see XMLEncoder.



lies mal richtig, es geht um serialisierte objekte dieser klasse und nicht darum, dass es die klasse in nem nächsten release nicht mehr geben wird.


----------



## Lazarus (20. Apr 2005)

nein. Also ich habe mal einen Artikel gelesen, daß IBM selber anfängt Pakete zu entwickeln, da das AWT von Sun schon seit geraumer Zeit nicht weiterentwickelt wird. Swing und AWT ist der Hauptunterschied, daß Swing ein "Leichtgewicht" und AWT ein "Schwergewicht ist". Das mit dem AWT ist so. Java soll ja so weit wie möglich plattformunabhängig sein. Das AWT nutzt Betriebssystemeigene Resourcen(Schwergewicht) um die Grafikausgaben vorzunehmen. Somit ist das AWT der kleinste gemeinsame Nenner von eigen OS. Swing ist um einiges lansamer und ziemlich Speicherhungrig. Der Grund dafür liegt darin, daß Swing alle Komponenten selber zeichnet. Also kein zugriff auf Betriessystemeigene Ressourcen zwecks Grafikausgabe. Damit lassen sich nun auf allen OS die selben Fenster auch der nicht ganz so 'urigen' Art erstellen.

cu


----------



## Corcovado (20. Apr 2005)

Was sind "serialised objects" denn nun eigentlich?

Das es nicht die komplette Klasse ist, soviel versteh ich auch gerade noch - was ich meinte ist einfach, dass sich v.a. dieses "ist nicht mehr vereinbar mit folgenden Versionen" aus welchem Grund auch immer, fuer mich stark nach in der Entwicklung anhoert. 

Ich glaube ich haette so aehnliche Dinge auch mal ueber die Gueltigkeit irgendwelcher Klassen gelesen (allerdings hab ich so eine Klasse dann doch nie benutzt, weil man standardmaessig immer was anderes ging).

Wie ist das allgemein mit der Entwicklung - gibt es andre Buechereien, die schneller sind als Swing aber auch "gute" Grafik benutzen und nicht in der Entwicklung stehn geblieben sind?


----------



## Roar (20. Apr 2005)

büchereien *gg* wenn dann bitte bibilotheken 
swign in der enwicklung stehen geblieben? ich bitte doch. mti 1.5 wurde swing sehr verschnellert und mit 1.6 werden viele bugs gefixt, neue komponenten kommen etc. swing is voll in der entwicklung
swt ist wohl schneller. musst dich informieren ob das das ist, was du suchst.


----------



## Corcovado (21. Apr 2005)

eieiei und zu den Rechtschreibfehlern sagt niemand was, danke, hab das eben mal kurz verbessert...

Bibliothek, Buecherei find ich pers keinen grossen Unterschied, hab ich schon immer gleichgesetzt - auch wenn andre sich dran stossen 

Ich meinte nicht das Swing stehn geblieben ist, sd AWT, wie gesagt, ich hab den Text nochmal durchgegangen, vielleicht isses bloed formuliert gewesen. Swing und die Entwicklung, das is eben das Problem, was ich etwas sehe mit Swing, in wie weit werden die Konzepte eben uebernommen oder gibts doch die ein oder andre Sache in Swing, die Aufgrund der noch starken Entwicklungsphase wohl durch andre wieder ersetzt wird.

Ich seh auch, dass Swing so extrem komfortabel ist, dass imo irgendwo anders grosse Haken sein muessen. Das is ja fast kein programmieren mehr, nur noch Dinge einzuhaengen - macht aber irre viel Spass  - nach meiner Erfahrung kann man oft mit dem schwierigeren Weg etwas zu entwickeln wiederum einiges herausholen, an Performance. 
Bsp C - fuer bsp Win son Fensterding in C zu basteln macht erst nach einigem Aufwand Spass, dafuer kann man an vielen kleinen Dingen, hinter der grafik drehn. Ich frage mich ob es soetwas nicht in aehnlicher Weise mit AWT auf sich hat, noch dazu, wenn Swing (erst) voll in der Entwicklung ist. Es muesste ja doch auch das gleiche moeglich sein mit AWT oder?

Tja und nun - gibt es andre Buechereien (Bibliotheken), die schon etwas ausgereifter sind als Swing, dafuer vielleicht aber noch etwas umstaendlicher aber mehr Komfort bieten als AWT?

...und was sind nun "serialised obj"?


----------



## AlArenal (21. Apr 2005)

AWT wurde quasi durch Swing ersetzt. Sun traut sich aber nicht alte Sachen mal einfach rauszuwerfen, ähnlich wie Intel und MS 

Genauso wird es auch bei Weiterentwicklungen von Swing laufen. Niemand ist so dumm seine neuen Produktversionen inkompatibel zu vorhandenen Versionen zu machen und sich somit die Userbase zu vergraulen.

Außer Swing, AWT und SWT gibts im Grunde ncihts ernstzunehmendes. Warum auch? Sie decken im Grunde alles ab. Klar gibt es immer Sachen, von den man sich wünschen würde, SUn würde sie mal mit aufnehmen, aber dafür ist Swing eben so wandlungsfähig, das man sich vieles selbst stricken kann. Limits hat man überall, aber unser Job ist es ja nicht über Probleme zu jammern, sondern Lösungen zu entwickeln.

"Leben in der Lage", wie es beim Bund hieß.

Persönlich sehe ich auch keinen Grund für noch ne Lib, weil das Rad nicht runder wird, wenn man es ständig neu erfindet...


----------



## Corcovado (21. Apr 2005)

> "Leben in der Lage", wie es beim Bund hieß.


Naja, bei uns Zivies etwas weniger pamphletisch - "...die Arbeit muss gmacht wern, des hilft nix!" 



> Außer Swing, AWT und SWT gibts im Grunde ncihts ernstzunehmendes. Warum auch?


Ich weiss nicht ob Java eigentlich offiziell standartisiert ist, aber der inoffizielle Standard wird dann fuer Grafik sicherlich AWT/Swing sein - das macht Sinn und erklaert fuer mich die vorhanden sein von nur diesen. Es ist sicherlich unlogisch 3 versch Buechereien (schon wieder...) in _einem_ Standard zu haben, die aber alle dasselbe - nur in 3 versch Versionen - implementieren. Es sei denn es gibt doch Unterschiede die diese Coexistenz aller drei rechtfertigen. Fuer mich heisst das nun wohl bei AWT die Performance und bei Swing der Komfort beim Entwickeln und letztendlich wohl auch bei allen Abwaertskompatibilitaet.

Das war aber genau auch mein Problem mit Swing und AWT, warum gibt es eigentlich beide und was soll dieses SWT - warum nicht nur eine einzige und diese aber mit den Moeglichkeiten von allen dreien?! Naja - nun sehe ich einiges umso klarer. Das eine als Weiterentwicklung des andern bspw. Ich wuerde den Sinn und Zweck anderer Buechereien (nein!) v.a. auch eher in spezielleren Aufgaben sehen, wie immer wenn man etwas spezielleres loesen will und vom Standard abeicht (bzw zusaetzliche Features benoetigt). Allerdings ist AWT/Swing wirklich sehr umfangreich, zumindest wenn man damit anfaengt...



Was sind denn nun "serialised objects" - ich will das wissen  ?
Kann man denn Swing und AWT eigentlich mischen, ich denke da an ausnutzen der Vorteile von beiden, bzw sollte man das ueberhaupt tun/ist das ueberhaupt moeglich?


----------



## AlArenal (21. Apr 2005)

AWT ist einfach zu eingeschränkt, nicht so dolle erweiterbar, ... Darum gabs mit Java 1.2 vor einigen Jahren Swing um Unzulänglichkeiten auszuräumen. Das war nicht möglich unter Beibehaltung der Konzepte hinter AWT. Hätte man versucht AWT zu erweitern um die Möglichkeiten zu schafen, die Swing bietet, hätte man Abwärtskompatibilität nicht gewähren können und das Ganze wäre von hinten durch die Brust in s Auge gegangen.

SWT stammt aber nicht von Sun und ist demnach auch nicht Bestandteil des JRE/JDK, sondern wurde von IBM für deren eigene Entwicklungsumgebung geschaffen, die dann ja in Open Source (Eclipse) überführt wurde.

AWT hat glaub ich noch seine Daseinsberechtigung auf Mobile Devices und zum Teil nutzt man es ja auch noch, wenn man Swing einsetzt, weil da noch eingies an EventHandling u.a. drin ist.

Es regt sich ja auch keiner drüber auf dass alle INtel CPUs noch ne missgestaltete A20 Gate, nen Real und nen Protected Mode haben.. 

Die eigentlich GUI-Komponenten von Swing und AWT mischt man besser nicht, weil das wie gekonnt und nicht gewollt aussieht. Im übrigen gibts keine grafische Komponenten in AWT, die es nicht auch in Swing gibt.

Serialisierung dient zur Übertragung und temporären Speicheurng von Objekten. Das kann man z.B. in XML machen. Da werden dann eben die Daten einer Instanz in XML überführt, so das man andernorts die Möglichkeit hat das Objekt wieder herzustellen. Ist quasi ein Beam-Vorgang 
Da der interne (verborgene) Aufbau der Komponenten aber Änderungen unterworfen ist, sind die serialsiierten Objekte unterschiedlicher  JRE-Versionen nicht nicht zwangsweise miteinander kompatibel, man nutzt die Serialisierungsmöglichkeiten darum nicht um Objekte dauerhaft abzuspeichern.


----------



## Corcovado (21. Apr 2005)

Real Mode und A20 Gate - woher kennt man denn sowas wenn man mit Java arbeitet??? 
Java Apps im Real Mode?!! - strange :autsch:  

Danke - gute Erklaerung der Situation!! Nun ist mir wieder einiges klarer in Dingen "Ueberblick, Leben in der Lage und so..."


----------



## AlArenal (21. Apr 2005)

Corcovado hat gesagt.:
			
		

> Real Mode und A20 Gate - woher kennt man denn sowas wenn man mit Java arbeitet???
> Java Apps im Real Mode?!! - strange :autsch:



Das war nicht auf Java bezogen, sondern eine Analogie


----------

