Antworten:
AWT ist eine Java-Schnittstelle zu nativem System-GUI-Code, der in Ihrem Betriebssystem vorhanden ist. Es wird nicht auf jedem System gleich funktionieren, obwohl es versucht.
Swing ist eine mehr oder weniger reine Java-GUI. Es verwendet AWT, um ein Betriebssystemfenster zu erstellen, malt dann Bilder von Schaltflächen, Beschriftungen, Text, Kontrollkästchen usw. in dieses Fenster und reagiert auf alle Mausklicks, Tasteneingaben usw. und entscheidet selbst, was zu tun ist anstatt das Betriebssystem damit umgehen zu lassen. Somit ist Swing zu 100% portabel und plattformübergreifend gleich (obwohl es skinnbar ist und ein "steckbares Erscheinungsbild" aufweist, das es mehr oder weniger so aussehen lässt, wie die nativen Fenster und Widgets aussehen würden).
Dies sind sehr unterschiedliche Ansätze für GUI-Toolkits und haben viele Konsequenzen. Eine vollständige Antwort auf Ihre Frage würde versuchen, all diese zu untersuchen. :) Hier sind ein paar:
AWT ist eine plattformübergreifende Schnittstelle. Obwohl das zugrunde liegende Betriebssystem oder das native GUI-Toolkit für seine Funktionalität verwendet wird, bietet es nicht Zugriff auf alles, was diese Toolkits leisten können. Erweiterte oder neuere AWT-Widgets, die möglicherweise auf einer Plattform vorhanden sind, werden auf einer anderen möglicherweise nicht unterstützt. Funktionen von Widgets, die nicht auf jeder Plattform gleich sind, werden möglicherweise nicht unterstützt, oder schlimmer noch, sie funktionieren auf jeder Plattform unterschiedlich. Früher haben die Leute viel Mühe investiert, um ihre AWT-Anwendungen plattformübergreifend konsistent zu machen. Beispielsweise versuchen sie möglicherweise, nativen Code von Java aus aufzurufen.
Da AWT native GUI-Widgets verwendet, kennt Ihr Betriebssystem diese und behandelt sie voreinander usw., während Swing-Widgets aus Sicht Ihres Betriebssystems bedeutungslose Pixel innerhalb eines Fensters sind. Swing selbst übernimmt das Layout und das Stapeln Ihrer Widgets. Das Mischen von AWT und Swing wird in hohem Maße nicht unterstützt und kann zu lächerlichen Ergebnissen führen, z. B. zu nativen Schaltflächen, die alles andere in dem Dialogfeld, in dem sie sich befinden, verdecken, da alles andere mit Swing erstellt wurde.
Da Swing versucht, alles Mögliche in Java zu tun, außer den sehr rohen Grafikroutinen, die von einem nativen GUI-Fenster bereitgestellt werden, war dies im Vergleich zu AWT ein erheblicher Leistungsverlust. Dies machte Swing leider langsam zu fangen. Dies ist jedoch in den letzten Jahren aufgrund optimierterer JVMs, schnellerer Maschinen und (ich nehme an) der Optimierung der Swing-Interna dramatisch geschrumpft. Heutzutage kann eine Swing-Anwendung schnell genug ausgeführt werden, um gewartet oder sogar schnell zu sein, und von einer Anwendung, die native Widgets verwendet, kaum zu unterscheiden. Einige werden sagen, dass es viel zu lange gedauert hat, bis dieser Punkt erreicht ist, aber die meisten werden sagen, dass es sich lohnt.
Schließlich möchten Sie vielleicht auch SWT (das für Eclipse verwendete GUI-Toolkit und eine Alternative zu AWT und Swing) ausprobieren, das eine Art Rückkehr zur AWT-Idee darstellt, über Java auf native Widgets zuzugreifen.
Der grundlegende Unterschied, den bereits alle erwähnt haben, besteht darin, dass einer schwer und der andere leicht ist . Lassen Sie mich erklären, was der Begriff "schweres Gewicht" im Grunde bedeutet, dass bei Verwendung der awt-Komponenten der native Code, der zum Abrufen der Ansichtskomponente verwendet wird, vom Betriebssystem generiert wird. Deshalb ändert sich das Erscheinungsbild von Betriebssystem zu Betriebssystem. Wo wie bei Swing-Komponenten liegt es in der Verantwortung von JVM, die Ansicht für die Komponenten zu generieren. Eine andere Aussage, die ich gesehen habe, ist, dass Swing MVC-basiert ist und awt nicht.
Swing vs AWT . Grundsätzlich stand AWT an erster Stelle und besteht aus einer Reihe schwerer UI-Komponenten (dh Wrapper für Betriebssystemobjekte), während Swing auf AWT mit einer umfangreicheren Reihe leichter Komponenten aufbaut.
Alle ernsthaften Arbeiten an der Java-Benutzeroberfläche werden in Swing statt AWT ausgeführt, das hauptsächlich für Applets verwendet wurde.
Soweit AWT nützlicher sein kann als Swing -
Aus diesem Unterschied zwischen AWT und Swing ergeben sich mehrere Konsequenzen.
AWT ist eine dünne Codeschicht über dem Betriebssystem, während Swing viel größer ist. Swing hat auch eine sehr viel umfangreichere Funktionalität. Mit AWT müssen Sie viele Dinge selbst implementieren, während Swing sie integriert hat. Für GUI-intensive Arbeit fühlt sich AWT im Vergleich zu Swing sehr primitiv an. Da Swing die GUI-Funktionalität selbst implementiert, anstatt sich auf das Host-Betriebssystem zu verlassen, kann es auf allen Plattformen, auf denen Java ausgeführt wird, eine reichhaltigere Umgebung bieten. AWT bietet nur eingeschränkt die gleiche Funktionalität auf allen Plattformen, da nicht alle Plattformen die gleichen Steuerelemente auf die gleiche Weise implementieren.
Swing-Komponenten werden als "Lightweight" bezeichnet, da für die Implementierung ihrer Funktionalität kein natives Betriebssystemobjekt erforderlich ist. JDialogund JFramesind Schwergewicht, weil sie einen Peer haben. So Komponenten wie JButton,
JTextAreausw., sind leicht , weil sie nicht ein O Peer haben.
Ein Peer ist ein vom Betriebssystem bereitgestelltes Widget, z. B. ein Schaltflächenobjekt oder ein Eingabefeldobjekt.
Schwingen:
AWT:
AWT 1. AWT belegt mehr Speicherplatz 2. AWT ist plattformabhängig 3. AWT erfordern das Paket javax.awt
Schaukeln 1. Swing belegt weniger Speicherplatz 2. Die Schwenkkomponente ist plattformunabhängig 3. Swing erfordert das Paket javax.swing