Swing (Java)
Swing is een platformonafhankelijk, “model-view-controller” GUI-framework voor Java, dat een single-threaded programmeermodel volgt. Bovendien biedt dit framework een abstractielaag tussen de codestructuur en de grafische presentatie van een op Swing gebaseerde GUI.
FoundationsEdit
Swing is platformonafhankelijk omdat het volledig in Java is geschreven. Volledige documentatie voor alle Swing-klassen is te vinden in de Java API Guide voor versie 6 of de Java Platform Standard Edition 8 API Specification voor versie 8.
ExtensibleEdit
Swing is een zeer modulaire architectuur, die het mogelijk maakt verschillende aangepaste implementaties van gespecificeerde framework-interfaces te “pluggen”: Gebruikers kunnen hun eigen aangepaste implementatie (s) van deze componenten om de standaard implementaties overschrijven met behulp van Java’s overervingsmechanisme via javax.swing.LookAndFeel.
Swing is een component-based framework, waarvan alle componenten uiteindelijk zijn afgeleid van de javax.swing.JComponent klasse. Swing-objecten vuren asynchroon gebeurtenissen af, hebben gebonden eigenschappen en reageren op een gedocumenteerde set van methoden die specifiek zijn voor de component. Swing-componenten zijn JavaBeans-componenten, die voldoen aan de JavaBeans-specificatie.
ConfigurableEdit
Swing’s zware afhankelijkheid van runtime-mechanismen en indirecte compositiepatronen stelt het in staat om tijdens runtime te reageren op fundamentele veranderingen in zijn instellingen. Een op Swing gebaseerde applicatie kan bijvoorbeeld de gebruikersinterface tijdens runtime hot swappen. Bovendien kunnen gebruikers hun eigen “look and feel”-implementatie leveren, waardoor uniforme veranderingen in de “look and feel” van bestaande Swing-toepassingen mogelijk zijn zonder programmatische wijziging van de applicatiecode.
Lichtgewicht UI
De hoge mate van flexibiliteit van Swing komt tot uiting in de inherente mogelijkheid om de GUI-besturingselementen van het native host-besturingssysteem (OS) te overschrijven voor de weergave van zichzelf. Swing “schildert” zijn besturingselementen met behulp van de Java 2D API’s, in plaats van een native user interface toolkit aan te roepen. Een Swing-component heeft dus geen corresponderende native OS GUI-component en is vrij om zichzelf weer te geven op elke manier die mogelijk is met de onderliggende grafische GUI’s.
In de kern is elke Swing-component echter afhankelijk van een AWT-container, aangezien (Swing’s) JComponent een uitbreiding is van (AWT’s) Container. Hierdoor kan Swing aansluiten op het GUI-beheerraamwerk van het host OS, inclusief de cruciale apparaat/scherm-afstemmingen en gebruikersinteracties, zoals het indrukken van toetsen of muisbewegingen. Swing “transponeert” gewoon zijn eigen (OS-agnostische) semantiek over de onderliggende (OS-specifieke) componenten. Zo schildert bijvoorbeeld elke Swing-component zijn weergave op het grafische apparaat in antwoord op een aanroep van component.paint(), die is gedefinieerd in (AWT) Container. Maar in tegenstelling tot AWT-componenten, die het schilderen delegeerden aan hun OS-native “zwaargewicht” widget, zijn Swing-componenten verantwoordelijk voor hun eigen rendering.
Deze omzetting en ontkoppeling is niet alleen visueel, maar strekt zich ook uit tot Swing’s beheer en toepassing van zijn eigen OS-onafhankelijke semantiek voor gebeurtenissen die worden afgevuurd binnen de component containment hiërarchieën. In het algemeen delegeert de Swing-architectuur de taak om de verschillende smaken van OS GUI-semantiek op een eenvoudig, maar gegeneraliseerd patroon af te stemmen aan de AWT-container. Voortbouwend op dat veralgemeende platform stelt het zijn eigen rijke en complexe GUI semantiek vast in de vorm van het JComponent model.
Losjes gekoppeld en MVCEdit
De Swing library maakt zwaar gebruik van het model-view-controller software design patroon, dat conceptueel de gegevens die worden bekeken ontkoppelt van de user interface controls waarmee ze worden bekeken. Daarom hebben de meeste Swing-componenten bijbehorende modellen (die worden gespecificeerd in termen van Java-interfaces), en kunnen de programmeurs verschillende standaardimplementaties gebruiken of hun eigen implementaties leveren. Het raamwerk biedt standaard implementaties van modelinterfaces voor al zijn concrete componenten. Voor het typische gebruik van het Swing-framework is het niet nodig eigen modellen te maken, aangezien het framework een reeks standaard-implementaties biedt die standaard op transparante wijze zijn gekoppeld aan de overeenkomstige JComponent child class in de Swing-bibliotheek. In het algemeen hebben alleen complexe componenten, zoals tabellen, bomen en soms lijsten, de aangepaste modelimplementaties rond de applicatiespecifieke gegevensstructuren nodig. Om een goed idee te krijgen van het potentieel dat de Swing architectuur mogelijk maakt, beschouw de hypothetische situatie waar aangepaste modellen voor tabellen en lijsten wrappers zijn over DAO en/of EJB services.
Typisch zijn Swing component model objecten verantwoordelijk voor het leveren van een beknopte interface die events fired definieert, en toegankelijke properties voor het (conceptuele) datamodel voor gebruik door het geassocieerde JComponent. Aangezien het algemene MVC-patroon een losjes gekoppeld samenwerkingspatroon voor objectrelaties is, biedt het model de programmatische middelen om event listeners aan het datamodelobject te koppelen. Typisch zijn deze events model-centrisch (bijv. een “rij ingevoegd” event in een tabel model) en worden door de JComponent specialisatie omgezet in een betekenisvolle event voor de GUI component.
Voorbeeld, de JTable heeft een model genaamd TableModel dat een interface beschrijft voor hoe een tabel toegang heeft tot tabel data. Een standaard implementatie hiervan werkt op een tweedimensionale array.
De view component van een Swing JComponent is het object dat wordt gebruikt om de conceptuele GUI control grafisch weer te geven. Een onderscheid van Swing, als een GUI framework, is de afhankelijkheid van programmatisch gerenderde GUI controls (in tegenstelling tot het gebruik van de native GUI controls van het host OS). Vóór Java 6 Update 10 was dit onderscheid een bron van complicaties bij het mixen van AWT controls, die native controls gebruiken, met Swing controls in een GUI (zie Mixen van AWT en Swing componenten).
Ten slotte, in termen van visuele compositie en management, geeft Swing de voorkeur aan relatieve layouts (die de positionele relaties tussen componenten specificeren) in tegenstelling tot absolute layouts (die de exacte locatie en grootte van componenten specificeren). Deze voorkeur voor een “vloeiende” visuele ordening is te danken aan zijn oorsprong in de applet-besturingsomgeving die het kader vormde voor het ontwerp en de ontwikkeling van de oorspronkelijke Java GUI-toolkit. (Conceptueel is deze opvatting van het layout-beheer zeer vergelijkbaar met die welke de rendering van HTML-inhoud in browsers informeert, en richt zich op dezelfde set van zorgen die de eerste motiveerde.)
Relatie met AWTEdit
Sinds vroege versies van Java, heeft een deel van de Abstract Window Toolkit (AWT) platformonafhankelijke API’s voor gebruikersinterface-componenten geleverd. In AWT wordt elke component weergegeven en gecontroleerd door een native peer-component die specifiek is voor het onderliggende windowingsysteem.
In tegenstelling daarmee worden Swing-componenten vaak beschreven als lichtgewicht omdat ze geen toewijzing van native resources in de windowing toolkit van het besturingssysteem vereisen. De AWT-componenten worden aangeduid als heavyweight components.
Veel van de Swing API is over het algemeen een aanvullende uitbreiding van de AWT in plaats van een directe vervanging. In feite bestaat elke Swing lichtgewicht interface uiteindelijk binnen een AWT zwaargewicht component omdat alle top-level componenten in Swing (JAppletJDialogJFrame, en JWindow) een AWT top-level container uitbreiden. Vóór Java 6 Update 10 werd het gebruik van zowel lichtgewicht als zware componenten binnen hetzelfde venster over het algemeen afgeraden vanwege Z-volgorde incompatibiliteiten. Latere versies van Java hebben deze problemen opgelost, en zowel Swing als AWT componenten kunnen nu worden gebruikt in een GUI zonder Z-volgorde problemen.
De kern rendering functionaliteit die wordt gebruikt door Swing om de lichtgewicht componenten te tekenen wordt geleverd door Java 2D, een ander onderdeel van JFC.
Relatie met SWTEdit
De Standard Widget Toolkit (SWT) is een concurrerende toolkit die oorspronkelijk is ontwikkeld door IBM en nu wordt onderhouden door de Eclipse-gemeenschap. SWT’s implementatie heeft meer gemeen met de zwaargewicht componenten van AWT. Dit biedt voordelen zoals een nauwkeuriger overeenkomst met de onderliggende native windowing toolkit, ten koste van een grotere blootstelling aan het native platform in het programmeermodel.
Er is veel gediscussieerd en gespeculeerd over de prestaties van SWT versus Swing; sommigen lieten doorschemeren dat SWT’s grote afhankelijkheid van JNI het langzamer zou maken wanneer de GUI component en Java gegevens moeten communiceren, maar sneller bij het renderen wanneer het datamodel in de GUI is geladen, maar dit is in beide gevallen nog niet bevestigd. Een vrij grondige reeks benchmarks in 2005 concludeerde dat noch Swing noch SWT duidelijk beter presteerden dan de ander in het algemene geval.