El Abstract Window Toolkit ( AWT ) es el conjunto de herramientas de ventanas , gráficos y widgets de interfaz de usuario dependiente de la plataforma original de Java , anterior a Swing . El AWT es parte de Java Foundation Classes (JFC), la API estándar para proporcionar una interfaz gráfica de usuario (GUI) para un programa Java. AWT también es el conjunto de herramientas de GUI para varios perfiles de Java ME . Por ejemplo, los perfiles de configuración de dispositivos conectados requieren entornos de ejecución de Java en teléfonos móviles para admitir el Abstract Window Toolkit.
Cuando Sun Microsystems lanzó Java por primera vez en 1995, los widgets AWT proporcionaban un nivel de abstracción reducido sobre la interfaz de usuario nativa subyacente. Por ejemplo, la creación de una casilla de verificación AWT haría que AWT llamara directamente a la subrutina nativa subyacente que creó una casilla de verificación. Sin embargo, la casilla de verificación en Windows no es la misma que la casilla de verificación en macOS o en los diversos tipos de Unix . Algunos desarrolladores de aplicaciones prefieren este modelo porque proporciona un alto grado de fidelidad al kit de herramientas de ventanas nativo subyacente y una integración perfecta con las aplicaciones nativas. En otras palabras, un programa GUI escrito con AWT parece una aplicación nativa de Microsoft Windows cuando se ejecuta en Windows, pero el mismo programa parece una aplicación nativa de Apple Macintosh cuando se ejecuta en una Mac, etc. Sin embargo, a algunos desarrolladores de aplicaciones no les gusta este modelo porque prefieren que sus aplicaciones se vean exactamente iguales en todas las plataformas.
En J2SE 1.2 , el kit de herramientas Swing reemplazó en gran medida a los widgets de AWT. Además de proporcionar un conjunto más completo de widgets de interfaz de usuario, Swing crea sus propios widgets (mediante el uso de Java 2D para llamar a subrutinas de bajo nivel en el subsistema de gráficos local) en lugar de depender del módulo de interfaz de usuario de alto nivel del sistema operativo. Swing ofrece la opción de utilizar el "aspecto y estilo" de la plataforma nativa o un aspecto y estilo multiplataforma (el "aspecto y estilo de Java") que se ve igual en todos los sistemas de ventanas.
El AWT proporciona dos niveles de API :
java.awt.datatransfer paquete para usar con el Portapapeles y la función de arrastrar y soltar .Canvas AWT también pone a disposición de las aplicaciones algunas funciones de nivel superior, como:
Ni AWT ni Swing son inherentemente seguros para subprocesos . Por lo tanto, el código que actualiza la GUI o procesa eventos debe ejecutarse en el subproceso de envío de eventos . Si no lo hace, puede producirse un bloqueo o una condición de carrera. Para solucionar este problema, una clase de utilidad denominada SwingWorker permite que las aplicaciones realicen tareas que consumen mucho tiempo después de los eventos de interacción del usuario en el subproceso de envío de eventos.
Cuando exista una versión Swing de un componente AWT, esta comenzará con J- y se deberá utilizar exclusivamente, reemplazando la versión AWT. Por ejemplo, en Swing, solo se debe utilizar JButton, nunca la clase Button. Como se mencionó anteriormente, las clases principales de AWT, como Color y Font, todavía se utilizan tal como están en Swing.
Al dibujar en Swing, utilice JPanel y anule paintComponent(Graphics g) en lugar de utilizar los métodos paint() de AWT.
Antes de Java 6 Update 12 , la combinación de componentes Swing y widgets AWT básicos solía generar efectos secundarios no deseados, ya que los widgets AWT aparecían sobre los widgets Swing independientemente de su orden z definido. Este problema se debía a que la arquitectura de representación de los dos conjuntos de herramientas de widgets era muy diferente, a pesar de que Swing tomaba prestados contenedores superiores pesados de AWT. [1]
A partir de Java 6 Update 12 , es posible combinar widgets Swing y AWT sin tener problemas de orden z. [2]
importar java.awt.* ; importar java.awt.event.WindowAdapter ; importar java.awt.event.WindowEvent ; clase pública MyApp { public static void main ( char [] args ) { Frame frame = new Frame ( " Aplicación" ); frame.add ( new Label ( " ¡Hola!" )); frame.setSize ( 500 , 500 ) ; frame.setLocationRelativeTo ( null ); // Centra la ventana frame.addWindowListener ( new WindowAdapter ( ) { @Override public void windowClosing ( WindowEvent e ) { frame.dispose (); // Libera recursos de pantalla nativos } }) ; frame.setVisible ( true ) ; } } Como AWT es un puente hacia la interfaz de usuario nativa subyacente, su implementación en un nuevo sistema operativo puede implicar mucho trabajo, especialmente si involucra alguno de los widgets de la GUI de AWT, porque cada uno de ellos requiere que sus pares nativos se desarrollen desde cero.
Se ha creado un nuevo proyecto, Caciocavallo, que proporciona una API de Java basada en OpenJDK para facilitar la implementación de AWT en nuevos sistemas. [3] [4] El proyecto ha implementado con éxito widgets AWT utilizando Java2D . [5] Desde entonces, todas las modificaciones necesarias del núcleo de JDK se han enviado a OpenJDK 7 , [6] lo que significa que Java ahora se puede utilizar en una pila de gráficos distinta a las proporcionadas por el JDK oficial ( X Window System , OpenGL o DirectX ), incluyendo una biblioteca externa y configurando algunas propiedades del sistema. Se está desarrollando un backend DirectFB para Caciocavallo [7] , al igual que un backend HTML5 ; el objetivo es implementar aplicaciones Swing existentes (sin soporte de Java) como aplicaciones web comunes que se ejecutan en un servidor web. [7] [8]
Ya no necesitas más de esos parches, con la última actualización de FontManager, ahora todo se sube al servidor, así que solo tienes que usar el repositorio de Cacio, es completamente autónomo.
java.awt( Documentación de la API de Javadoc de AWT )