Hace un tiempo, basado en la experiencia que tuve y tengo haciendo soft con GUIs, al utilizar Java se me plantearon las dos alternativas serias que existen en el lenguaje: Swing y SWT.
Si bien el tema es motivo de «guerra santa» permanente entre la gente que está a favor de Sun, Netbeans y por último, Swing contra la de IBM, Eclipse y SWT, yo probé un poquito de las dos. Me gustó más SWT, más que nada porque Swing se veía horrible y lento en Linux (y no me parece cambiar de SO por ese motivo). Así que, como el que tenía la decisión era yo, hice entre otras cosas chiquitas, un programita para enviar SMS a través de internet a los celulares de Argentina, Sonar.
Sonar está escrito en Java+SWT, y como éste último utiliza los widgets nativos de la plataforma, existe un swt.jar para interfacear desde java (lo que se llama un wrapper), que llama a las distintas librerías compartidas nativas, según la plataforma donde esté corriendo.
Algo así, comparado con Swing:
(Extraído de http://www.developer.com/open/article.php/10930_3316241_2)
No quiero seguir con esta intro, para eso está Google, la Wikipedia y éste link. 😀
Como SWT utiliza librerías nativas, cada vez que se quiera ejecutar un programa que las utilice, debe ejecutarse configurando en el java.library.path, la ubicación de las librerías nativas (excepto todo lo que pertenezca al JDK en sí). Y SWT no está en la JDK.
Por ejemplo, este script Bash de inicio es típico de un programa en SWT:
#!/bin/bash
export PATH=$PATH:$(dirname $(readlink -f $0))
java -Djava.library.path=./swt/ -jar sonar.jar
(El mecanismo de MANIFEST.MF que incluye el .jar incluye por su parte a ./swt/swt.jar y listo.)
Esto era un inconveniente, más que nada para los usuarios de Swing, que no estaban acostumbrados a esto, ya que Swing está dentro de la JDK. Mecanismos como Java Web Start (que me parecen muy útiles) eran complicados de implementar con SWT, siendo éste el principal motivo.
El punto es que una buena noticia de la última versión de desarrollo de SWT (la 3.3M4) va a incluir las librerías nativas en el mismo swt.jar, haciendo innecesario definir esta constante.
Esto permite que todos los mecanismos estándar de ejecución de aplicaciones (hacer «doble click» en el .jar en Windows y Linux, por ejemplo) se apliquen a SWT tal como se aplican a Swing.
SWT, en mi opinión, es uno de los mejores toolkits multiplataforma (que utilizan el look and feel nativo) que conozco. Sólo con Java está bueno. Combinado con Jython es una masa!
Más info de la noticia:
Saludos!
Marcelo
Deja una respuesta