Artículo 3 sobre la plataforma ECLIPSE

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:ArticuloEclipseArt_Eclipse3Copia 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ía
serlo 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. .

Artículo 3 sobre la plataforma ECLIPSE

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Artículo 3 sobre la plataforma ECLIPSE

Similar to Artículo 3 sobre la plataforma ECLIPSE (20)

More from torrubia

More from torrubia (20)

Artículo 3 sobre la plataforma ECLIPSE