Artículo 3 ECLIPSE y JAVA

EL ARCHIPIÉLAGO ECLIPSE (PARTE 2 DE 4)

Fecha de la última revisión: 21.05.2014

Miguel Ángel Abián mabian ARROBA aidima PUNTO es

14. SWT: La controversia está servida. Introducción. El Standard Widget Tookit de la plataforma Eclipse ha resultado ser el aspecto de Eclipse que

mayores rechazos, adhesiones y controversias ha provocado en la comunidad Java. SWT es la respuesta, para el desarrollo de interfaces de usuario, de IBM al AWT y al Swing de Java. De acuerdo con la documentación oficial de Eclipse, he aquí la descripción del componente Standard Widget Toolkit: "El componente SWT está diseñado para proporcionar acceso portable y eficiente a las facilidades de la interfaz de usuario de los sistemas operativos donde está implementado".

El propósito original de Swing consistía en proporcionar a las aplicaciones Java el mismo aspecto consistente en todas las plataformas (con la posibilidad de imitar hasta cierto punto la apariencia nativa). Aunque con Swing pueden producirse, con esfuerzo, aplicaciones Java de aspecto similar a las aplicaciones nativas, su rendimiento, en comparación con estas últimas, siempre ha sido pobre.

El motivo de este pobre rendimiento con AWT/Swing reside en que el código que interacciona directamente con los widgets nativos está escrito en C (forma parte de la biblioteca nativa AWT) y no está disponible para Swing. También la API que proporcionan los widgets nativos está escrita en C y Swing no puede acceder directamente a ella. El SWT de Eclipse utiliza una estrategia sumamente ingeniosa y mucho más eficiente, utilizando la API JNI (Java Native Interface) de Java, que permite a los programas Java invocar código escrito en C, para llamar directamente a las APIs escritas en C del sistema operativo nativo. SWT, a través de la API JNI; consigue siempre que sea posible una correspondencia uno a uno (one-to-one mapping) entre los métodos nativos Java y las llamadas a la API gráfica nativa (escrita en C) subyacente bajo el sistema operativo.

SWT usa widgets nativos siempre que sea posible, excepto cuando un tipo de widgets no está disponible en todas las plataformas. En ese caso, SWT lo emula en las plataformas que no lo soportan nativamente. Por ejemplo, Motif no proporciona un widget nativo de tipo árbol, por lo tanto el SWT proporciona un widget árbol emulado con la misma API que la implementación nativa en Windows. Ningún usuario de Motif notará algo raro en un componente SWT árbol pues, como no existe de forma nativa en la plataforma, no tiene criterio para saber cómo debe comportarse.

Una vez obtenida la correspondencia uno a uno, el desarrollador puede olvidarse del código JNI-C y de los detalles de bajo nivel del sistema operativo que éste oculta, y limitarse a utilizar los métodos públicos que proporcionan las clases de SWT. Por así decirlo, simplificando un poco, SWT encapsula de modo transparente el sistema operativo nativo a través del JNI, permitiendo utilizar todas las características de los widgets nativos. Actúa, en definitiva, como una fina capa entre Java y las bibliotecas de la API gráfica nativa. En comparación con el AWT, SWT evita el uso de una capa separadora (y ralentizadora) como la del AWT.

Cada plataforma con una implementación del SWT tiene su propia biblioteca Java, que utiliza la API JNI para establecer una correspondencia uno a uno entre los métodos Java y los métodos de la API

Copyright (c) 2003-2014, Miguel Ángel Abián. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en http://www.javahispano.org/licencias/).

Page 1 of 9ARCHIPIÉLAGO ECLIPSE

21/05/2014file://F:\ArticuloEclipse\Art_Eclipse3\Copia de ArticuloEclip...

gráfica nativa, y todas estas bibliotecas implementan una serie común de clases. Estas clases comunes, con las mismas declaraciones de sus métodos públicos, permiten que el código Java que use SWT se ejecute sin necesidad de cambios en cualquier otra plataforma donde exista una implementación del SWT. En ese sentido, SWT es transportable y nativo simultáneamente, por contradictorio que parezca (en SWT todas las interfaces directas a la API gráfica nativa están escritas en Java, excepto la de más bajo nivel).

Esta última faceta paradójica quizás quede más clara con un ejemplo: consideremos un widget SWT Button y supongamos que trabajamos con implementaciones del SWT en Windows y Solaris (olvidemos temporalmente que hay implementaciones de SWT para más plataformas).

La clase Button del SWT en Windows, una subclase de la clase abstracta Control, tiene el siguiente

código: package org.eclipse.swt.widgets; // Imports import java.lang.String; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.widgets.Control; import org.eclipse.swt.internal.win32.TCHAR; import org.eclipse.swt.events.SelectionListener; import org.eclipse.swt.internal.win32.LRESULT; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.graphics.Image; public class Button extends Control { // Fields Image image; static final int ButtonProc; static final TCHAR ButtonClass; static final int CheckWidth; static final int CheckHeight; // Constructors public Button(Composite p0, int p1) { } // Methods static { } public void addSelectionListener(SelectionListener p0) { } int callWindowProc(int p0, int p1, int p2) { } static int checkStyle(int p0) { } void click() { } public Point computeSize(int p0, int p1, boolean p2) { } int defaultBackground() { } int defaultForeground() { } public int getAlignment() { } boolean getDefault() { } public Image getImage() { } String getNameText() { } public boolean getSelection() { } public String getText() { } boolean isTabItem() { } boolean mnemonicHit(char p0) { } boolean mnemonicMatch(char p0) { } void releaseWidget() { }



public void removeSelectionListener(SelectionListener p0) { } void selectRadio() { } public void setAlignment(int p0) { } void setDefault(boolean p0) { } public boolean setFocus() { } public void setImage(Image p0) { } boolean setRadioFocus() { } public void setSelection(boolean p0) { } public void setText(String p0) { } int widgetStyle() { } TCHAR windowClass() { } int windowProc() { } LRESULT WM_GETDLGCODE(int p0, int p1) { } LRESULT WM_KILLFOCUS(int p0, int p1) { } LRESULT WM_SETFOCUS(int p0, int p1) { } LRESULT wmCommandChild(int p0, int p1) { } LRESULT wmDrawChild(int p0, int p1) { } } La clase Button en Solaris presenta otro código, pero todos los métodos públicos se declaran igual

que en la clase Button de Windows (por ejemplo, la declaración public boolean setFocus() también aparece -idéntica- en la clase SWT de Button en Solaris, pero no hay un método con una declaración int callWindowProc(int p0, int p1, int p2) en la clase Button de Solaris, puesto que callWindowProc no se define como un método público).

Por supuesto, los métodos públicos de cada clase se implementan de modo completamente distinto en Solaris y Windows; en cada caso se usa la API gráfica nativa de cada plataforma, mediante el uso de JNI. La implementación de cada método en Solaris no será portable a Windows y viceversa, pero el código Java que utilice los métodos públicos de Button sí lo será puesto que ambas plataformas tienen implementaciones de SWT.

Por ejemplo, la sentencia miBoton.setText("Soy un cuadro de diálogo SWT") hará llamadas, a través de JNI, a métodos nativos completamente diferentes en Windows y Solaris, pero funcionará igual en ambas plataformas (dando distintas presentaciones gráficas, claro está) al tener la misma declaración: public void setText(String p0) en ambas. El código Java que llame al SWT no necesita saber ni preocuparse (de hecho, si lo hiciera se violaría el principio de encapsulación y el SWT habría sido mal diseñado) de la implementación de las clases SWT ni del código JNI-C que hace llamadas a la API gráfica nativa.

Las bibliotecas JNI SWT se deben compilar para cada plataforma (dando un fichero con extensión .dll en Windows y otro con extensión .so en Solaris). Un programa que utilice SWT usa las bibliotecas Win32 nativas de Windows en Windows, y las bibliotecas Motif en Solaris.



Fig. 14. SWT en acción: La plataforma Eclipse en Linux-Motif. Extraído de la documentación

oficial de Eclipse.

Fig. 15. SWT en acción: La plataforma Eclipse en Windows XP. Extraído de la

documentación oficial de Eclipse. Al permitir la API JNI que las aplicaciones Java puedan interaccionar directamente con el código

nativo, SWT es mucho más rápido que AWT/Swing, consume muchos menos recursos y se integra perfectamente con el entorno nativo de cada plataforma (pudiendo reflejar inmediatamente cualquier cambio en el L&F del interfaz de usuario del sistema operativo subyacente, como sucede con el skinning



de Windows XP). Cualquier aplicación Java podría utilizar JNI para establecer una correspondencia entre los métodos Java y las capacidades gráficas nativas de la plataforma usada, pero SWT evita a los programadores tener que escribir su propio código JNI (tarea que, desde luego, dista mucho de ser trivial y que, para este caso, requiere un buen conocimiento de la plataforma -sistema operativo, arquitectura hardware y entorno gráfico- con la que se está trabajando).

15. SWT: Ventajas e inconvenientes. Las críticas a Eclipse, dejando aparte legítimos intereses comerciales mejor o peor encubiertos, se

han encauzado hacia estos dos frentes: 1) SWT limita la portabilidad de las aplicaciones Java que lo utilicen, y 2) SWT no es un estándar (al contrario que AWT/Swing).

Por su propia naturaleza, SWT limita la estimada capacidad multiplataforma de Java y la portabilidad de la propia plataforma Eclipse, al hacer uso de capacidades gráficas nativas. Una aplicación Java que use SWT sólo podrá funcionar en plataformas donde exista una implementación de SWT. Siempre puede usarse Eclipse para escribir aplicaciones Java que usen AWT o Swing, y el código será 100% transportable a otras plataformas, tengan o no implementaciones de Eclipse (siempre, claro está, que existan implementaciones de la máquina virtual Java). Ojo: que se pueda usar Eclipse para escribir aplicaciones Java con componentes Swing no guarda relación alguna con que puedan usarse componentes Swing (o AWT) en Eclipse. Esta última situación requiere un análisis detenido del problema en cuestión para determinar si es viable.

Fig. 16. Ejemplo de una aplicación, desarrollada con Eclipse, que utiliza componentes Swing. Muchas veces hay que llegar a un compromiso entre lo que se desea y lo que se puede. Conseguir

construir aplicaciones cliente Java que puedan competir en igualdad de condiciones (o casi) con aplicaciones nativas cliente (como las de Windows) sin echar mano de las capacidades gráficas nativas del sistema operativo subyacente resulta sencillamente imposible. Swing posiblemente mejorará, pero no podrá superar, en cuanto a rendimiento y semejanza a las aplicaciones nativas, a SWT.

Es cierto que Swing no está siendo todo lo bien utilizado por los programadores Java que podríaserlo y que, con un poco de trabajo y conociéndolo bien, puede proporcionar aplicaciones más parecidas



a las nativas Windows, pero cuesta mucho tiempo y esfuerzo conseguir programar de forma óptima en Swing, además de ser necesario tener muy claro el diseño de cada interfaz desde el principio. Muchos programadores prefieran concentrarse en otros problemas que no sean la interfaz gráfica. Existe en http://www.jgoodies.com/metamorphosis una aplicación llamada Metamorphosis que incluye una aplicación de ejemplo que simula el L&F de Eclipse mediante Swing y da consejos sobre la construcción de interfaces de usuario con Swing. La aplicación ha sido realizada por Karsten Lentszch.

AWT y Swing tienen la ventaja indiscutible de ser estándares Java. No se puede, por ejemplo, disponer de SWT en IRIX, OS/390, OS/400, OS/2 o FreeBSD, al no haber todavía implementaciones para estas plataformas, mientras que puede desarrollarse con AWT/Swing en cualquier plataforma donde exista una maquina virtual Java (como ocurre con las anteriores).

Actualmente SWT se encuentra disponible para: - HP UX/Motif - AIX/Motif - Linux/Motif - Linux/GTK - Linux/QT - MacOS/Carbon - Windows/Windows - Windows CE/Windows - Solaris/Motif - QNX/Photon No todas las implementaciones se encuentran en el mismo estadio de desarrollo. Posiblemente la de

Windows sea la más completa y comprobada (lo cual apunta directamente las intenciones de IBM). La de Mac OS X, sin embargo, presenta [Marzo, 2003] bastantes características ausentes y no está muy optimizada, pese a los numerosos retrasos que lleva con respecto a los planes previstos.

Swing, en particular, constituye una biblioteca gráfica con una arquitectura robusta y compleja, en

cuyo diseño se usaron patrones y todas las características de la orientación a objetos, mientras que la biblioteca SWT es más sencilla y fácil de utilizar, aunque más limitada. Lógicamente, al ser SWT relativamente nuevo, no se conocen del todo sus bugs y limitaciones, aunque hay indicios de que las implementaciones actuales pueden tener problemas con la escalabilidad. Un aspecto de SWT que podría llegar a ser problemático es la necesidad de liberar recursos. En SWT se requiera la liberación explícita de recursos (fuentes, colores, etc.) por parte del programador. Tal y como figura en la documentación de Eclipse: Si lo creó, libérelo. Esta regla, muy sencilla de aplicar con pequeñas aplicaciones, puede tornarse muy difícil de aplicar en proyectos de cierta envergadura. Es más, el recolector de basura de Java se creó para evitar los errores de liberación de recursos tan comunes en C++. ¿Será necesario que aparezca de aquí a un tiempo un recolector de objetos SWT?

[Nota técnica: En Swing es necesario utilizar el método dispose() con las clases derivadas del tipo ventana (JFrame y JDialog) para liberar recursos una vez se ha terminado con ellas. Independientemente de si se trata de un error o no (posiblemente sí), estos casos particulares constituyen excepciones.]

Personalmente, me gusta que las aplicaciones Java tengan la misma apariencia en todas las plataformas, pero comprendo que los usuarios finales de aplicaciones cliente Java puedan sentirse desconcertados o confundidos. Sin embargo, llevo ya un tiempo trabajando con Eclipse en Windows 98, XP y Red Hat, y reconozco que SWT consigue un mimetismo casi perfecto con respecto al aspecto de las aplicaciones nativas: un usuario de aplicaciones que utilicen el SWT no se dará cuenta de que esta ejecutando una aplicación Java (cosa muy difícil de conseguir por los programadores sin suficiente experiencia con Swing: cualquier usuario que, ante una aplicación Swing realizada por un principiante, no note al poco tiempo algo raro con respecto a las aplicaciones Windows posiblemente sea ciego o haya podido escapar con éxito de utilizar cualquier aplicación hasta la fecha. Mi enhorabuena a aquellos o aquellas que estén en este último caso; es duro conseguirlo, pero no vale la pena).

Existen herramientas profesionales que utilizan Swing (JBuilder, IntelliJ, Forte for Java) y que permiten desarrollar aplicaciones empresariales, pero su voracidad de recursos y su escasa velocidad no tienen igual en el campo de las herramientas nativas. En el caso de JBuilder, algunos nostálgicos recuerdan, en los foros estadounidenses del producto, con añoranza y lágrimas virtuales y materiales en los ojos los buenos tiempos en que JBuilder no estaba escrito en Java e iba mucho más rápido.



Pienso que disponer de SWT ofrece una posibilidad más, completamente opcional, a los desarrolladores en Java. Dado que actualmente Java se emplea sobre todo en aplicaciones servidor sin componentes gráficos, SWT podría, quién sabe, revitalizar un poco el interés de los usuarios en los clientes Java.

Fig. 17. Tabla comparativa entre Swing y SWT.



Fig. 18. SWT en acción: La plataforma Eclipse se adapta automáticamente al skin de

Windows XP. Extraído de la documentación oficial de Eclipse.

16. Pero ¿es realmente original el SWT de Eclipse? ¿Tenía otra elección IBM? El planteamiento en que se basa el Standard Widget Toolkit de Java, a medio camino entre el AWT

y Swing, no es nuevo. Antes que Eclipse existían (y existen) proyectos de bibliotecas gráficas para Java, de código fuente abierto, en los que se usaba la API JNI para acceder directamente al código nativo, pero ninguno de ellos ha tenido la popularidad del SWT ni su extensión a tantas plataformas.

El SWT de IBM tampoco constituye la única alternativa realista al AWT y a Swing. Por poner un solo ejemplo, la biblioteca LwVCL (Zaval Light Weight Visual Component Library) constituye una alternativa "seria" al AWT y Swing; es un proyecto free source bajo licencia GNU GPL, desarrollado integramente en Java, que proporciona una solución alternativa al AWT y Swing sin menoscabo del rendimiento y sin necesidad de grandes recursos hardware. Tiene algunos inconvenientes, pero, dado el pequeño tamaño de LwVCL (unos 150 Kb), proporciona una solución muy aceptable para muchas aplicaciones.

Ni siquiera el debate entre los partidarios de widgets con la apariencia de los nativos y los partidarios de componentes con la misma apariencia en todas las plataformas es nuevo. Ya surgió con SmallTalk () y provocó discusiones dentro de la propia IBM antes de la gestación de Eclipse. Por cierto, la batalla la ganaron los partidarios de los widgets nativos.

La originalidad de Eclipse reside en dos puntos: a) Proporciona una API común y transportable, que se implementa en cada plataforma usando los

widgets nativos. Esta API común y transportable (y su implementación en más de una plataforma, por no decir en la mayoría) está ausente en los proyectos open source que utilizan JNI. Por supuesto, resulta más fácil llevar a buen puerto un proyecto tan costoso si detrás hay empresas como IBM.

b) Proporciona un conjunto de widgets o componentes gráficos comunes en todas las plataformas, relacionados con los nativos siempre que sea posible, sin reducirse al pequeño conjunto de componentes AWT comunes en todas las plataformas. Como se vio en el anterior apartado, cuando no hay un widget nativo, SWT lo emula.

Puede considerarse que IBM, con el SWT, está haciendo "una reinvención de la rueda... sólo que

no tan bonita o redonda" (BigBlueSmoke) o que "está rompiendo la filosofía básica de Java" (Sun o BEA), pero no creo que -en realidad- tuviera ninguna otra opción. Para intentar conseguir que Eclipse



sea un estándar en el desarrollo de herramientas de desarrollo competitivas y eficaces, IBM necesitaba una interfaz gráfica impactante y que pudiera competir rápidamente en igualdad de condiciones (no maniatada y con un ojo cerrado) con las aplicaciones nativas. Resulta imposible hablar del triunfo de un proyecto así sin haber penetrado en el mercado de desarrolladores de aplicaciones cliente para Windows, un sector en el que Java nunca ha destacado (en parte, sólo en parte, por la apariencia y sensación de Swing). Queda en manos de cada desarrollador utilizar Eclipse para producir aplicaciones que usen componentes SWT o AWT/Swing.

[Fin de la tercera parte]

Acerca del autor

Miguel Ángel Abián Miguel Ángel Abián nació en Soria. Obtuvo la suficiencia investigadora en el Dpto. de Física

Aplicada de la Universidad de Valencia con una tesina sobre electromagnetismo. Realizó varios cursos de doctorado relacionados con electromagnetismo, electrónica, semiconductores y cristales fotónicos. Ha recibido becas del IMPIVA (Instituto de la Mediana y Pequeña Industria Valenciana) y de la Universidad Politécnica de Valencia. Cursó un Máster estadounidense en UML y Java y otro sobre tecnologías de Internet/Intranet. Se incorporó en 1998 a AIDIMA, donde ha participado como investigador en 24 proyectos de investigación nacionales e internacionales relacionados con la Web semántica, tecnologías de la información, madera en construcción, biosensórica, bioelectrónica, telecomunicaciones, visión artificial; así como en la Red de Excelencia de la Comisión Europea INTEROP 2003-2007. Algunos de los proyectos europeos relacionados con las tecnologías semánticas en los que ha participado son ATHENA y STASIS (http://www.stasis-project.net/). El año 2006 estuvo cuatro meses como investigador invitado en el departamento Lehrstuhl für Messsystem und Sensortechnik de la Universidad Politécnica de Munich (TUM), donde colaboró en el desarrollo de nuevos métodos para la detección de defectos en superficies acabadas y en el diseño e implementación de sistemas distribuidos de sensores para el sector del automóvil y de energías renovables. En 2007 recibió un premio BANCAJA-UPV por un proyecto relacionado con la calidad interna de la madera. En 2009 recibió el premio internacional Schweighofer Innovation Prize -el premio más prestigioso en el sector forestal y de la madera- por su aportación al desarrollo de nuevas tecnologías de evaluación no destructiva de la madera en construcción. Actualmente es Responsable del Departamento de Tecnología y Biotecnología de la Madera y del Área de Construcción de Madera. Es coautor de 7 libros y guías técnicas relacionadas con el uso de la madera en la construcción y la visión artificial. También ha publicado varios artículos científicos en revistas como IEEE Transactions on Microwave Theory and Techniques y Wood Science and Technology. Ha participado como ponente en congresos y conferencias como European Congress on Computational Methods in Applied Sciences and Engineering, IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, International Conference on Space Structures (IABSE-IASS) y en reuniones COST (European Cooperation in Science and Technology). Ha publicado más de 22 artículos técnicos en revistas sectoriales y técnicas. Es autor o coautor de 8 patentes, algunas de ellas en trámite. Tres de ellas corresponden a dispositivos y métodos para detectar la biodegradación de la madera en construcción. Actualmente, entre otros proyectos como SHBUILDINGS, WOODTECH, WOODRUB y CELLUWOOD, ha trabajado en SEMCONCEPT, un proyecto de I+D+i para aplicar tecnologías semánticas (ontologías, buscadores semánticos) en el diseño conceptual de productos industriales. Sus intereses actuales son la evolución de la programación orientada a objetos, Java, la Web semántica y sus tecnologías, la arquitectura orgánica, el surrealismo y París, siempre París. .



Documents

Artículo 3 ECLIPSE y JAVA