Abstract Window Toolkit (AWT) är det ursprungliga plattformsoberoende GUI-fönsterbiblioteket (Widget toolkit) för Java-språket . AWT är nu en del av Java Foundation Classes (JFC), ett standard -API för att implementera ett GUI i ett Java-program.
AWT är också standard GUI-biblioteket för vissa Java ME- profiler . Till exempel kräver profiler för konfiguration av anslutna enheter Java-runtime på mobiltelefoner för att stödja AWT.
När Sun Microsystems släppte Java för första gången 1995, gav AWT- widgets ett tunt lager av abstraktion över det ursprungliga användargränssnittet . Att skapa en AWT- kryssruta gör till exempel att AWT direkt anropar en inbyggd subrutin på lägre nivå som skapar kryssrutan. En kryssruta på Microsoft Windows är dock inte riktigt detsamma som en kryssruta på Mac OS eller olika varianter av Unix . Vissa utvecklare föredrar den här modellen eftersom den ger en hög grad av överensstämmelse med verktygssatsen för huvudfönster och sömlös integration med inbyggda applikationer. Med andra ord, ett GUI-program som är skrivet med AWT ser ut som en inbyggd Microsoft Windows-applikation när den körs på Windows, och ser samtidigt ut som en inbyggd Apple Macintosh- applikation när den körs på en Mac, etc. Vissa utvecklare gillar dock inte denna modell eftersom de föredrar att deras appar ser likadana ut på alla plattformar.
I J2SE 1.2 har AWT-widgets till stor del ersatts av de från Swing . Förutom att tillhandahålla en rikare uppsättning av användargränssnittselement, ritar Swing sina egna widgets (med Java 2D för att anropa lokala grafiska undersystemrutiner på låg nivå ) istället för att förlita sig på operativsystemets användargränssnittsmodul på hög nivå. Swing ger möjlighet att använda antingen ett system "look and feel" som använder plattformens ursprungliga "look and feel" eller en cross-platform look and feel ("Java Look and Feel") som ser likadan ut på alla plattformar. Swing använder dock AWT för att interagera med det ursprungliga fönstersystemet.
AWT tillhandahåller två API- nivåer :
AWT tillhandahåller också applikationer med vissa funktioner på hög nivå:
Varken AWT eller Swing är i sig trådsäkra . Således måste kod som uppdaterar GUI eller hanterar händelser köras på händelseutsändningstråden EDT ) . Underlåtenhet att göra det kan resultera i dödläge eller ett tävlingstillstånd. För att lösa detta problem tillåter en verktygsklass applikationer att exekvera "tunga" gränssnittshändelsehanterare på händelsebearbetningstråden. SwingWorker
Från och med Java 6#Java SE 6 Update 10 , hade en blandning av Swing- komponenter och grundläggande AWT-widgets ofta oönskade biverkningar, med AWT-widgets som visades ovanför Swing-widgets, oavsett deras specifika staplingsordning . Anledningen till detta problem är att renderingsarkitekturen för de två widgetverktygssatserna är väldigt olika, trots att Swing lånat AWT:s tungviktscontainrar på högsta nivå [ 1] .
Från och med Java 6#Java SE 6 Update 12 är det möjligt att blanda Swing- och AWT-widgets utan problem med stackorder.
Eftersom AWT är en brygga till det underliggande inbyggda användargränssnittet kan det vara ett stort jobb att implementera det på ett nytt operativsystem , främst för en uppsättning widgets som kräver att inbyggda peers utvecklas från grunden för var och en av AWT-widgetarna.
Samtidigt med utvecklingen av Java började Caciocavallo- projektet utvecklas . Dess mål är att tillhandahålla Java API:er baserade på OpenJDK för att underlätta skrivning av AWT-implementationer för nya operativsystem [2] . Java2D [3] används för att bygga gränssnittet . Alla nödvändiga ändringar ingår i JDK sedan OpenJDK 7 [4] .
| Verktygssatser (uppsättningar) med GUI-element | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| låg nivå |
| ||||||||||||||||||||||||||
| hög nivå |
| ||||||||||||||||||||||||||