Aplicación de escritorio Java: SWT vs. Swing [cerrado]

158

Actualmente soy desarrollador web y estoy pensando en crear mi primera aplicación de escritorio real. La idea es crear una herramienta que automatice una tarea muy repetitiva en una aplicación web donde no hay API disponible.

Sé que quiero usar Java. Lo utilicé antes para material web, conozco bastante bien la sintaxis y quiero que la aplicación sea multiplataforma lo más fácil posible.

Donde no estoy tan seguro es si debo usar SWT o Swing. Como mi audiencia principal usa Windows, quiero verlo lo más nativo posible allí. Linux y Mac deberían funcionar, pero el aspecto no es tan importante aquí.

Entonces, ¿cuáles son los argumentos a favor y en contra de cada UI Framework, Swing o SWT?

Gracias.

PD: desarrollo en Windows usando Eclipse. Pero estaba pensando en jugar con Netbeans.

java swing swt janpio
fuente
Pregunta difícil. :-) Me gustaría ir con Swing. Pero, no tenga PRO o CONs para esa decisión.
Pablo Santa Cruz
Q duplicada. Busque Swing vs. SWT Q que ya se le preguntó en SO. FWIW, uso Swing solo porque aprendí de esa manera. Hay bibliotecas nativas de apariencia (ver looks de jgoodies)
Jason S
"construir una herramienta que automatice una tarea muy repetitiva en una aplicación web" - ¿alguna información sobre esto? Puede haber una herramienta existente, y cuestiono la necesidad de una aplicación de escritorio para automatizar esto, puede funcionar en su caso en este momento, pero ¿qué pasa si cambia a una solución alojada?
Nate
No necesita aprender un marco GUI para una aplicación de escritorio. Si puede usar html css y js (que supongo que es así) puede usar Electron para crear aplicaciones de aspecto nativo con idiomas web.
Pranav A.
El electrón se inventó unos años después de que hice esta pregunta;) Pero, por supuesto, hoy tienes razón.
Janpio

Respuestas:

152

Swing profesional:

  • parte de la biblioteca de Java, no se necesitan bibliotecas nativas adicionales
  • funciona de la misma manera en todas las plataformas
  • Editor de GUI integrado en Netbeans y Eclipse
  • buenos tutoriales en línea de Sun / Oracle
  • Compatible con extensiones oficiales de Java (como Java OpenGL)

Contras Swing:

  • La apariencia nativa puede comportarse de manera diferente al sistema nativo real.
  • Los componentes pesados ​​(nativo / awt) ocultan los componentes de oscilación, no es un problema la mayoría de las veces ya que el uso de componentes pesados ​​es bastante raro

Pros SWT:

  • usa elementos nativos cuando es posible, por lo que siempre el comportamiento nativo
  • compatible con eclipse, editor de interfaz gráfica de usuario VEP (VEP también es compatible con Swing y AWT)
  • gran cantidad de ejemplos en línea
  • tiene un puente awt / swt integrado para permitir el uso de componentes awt y swing

Contras SWT:

  • requiere bibliotecas nativas para cada sistema compatible
  • Es posible que no admita todos los comportamientos en todos los sistemas debido a los recursos nativos utilizados (opciones de sugerencias)
  • gestión de recursos nativos, mientras que los componentes nativos a menudo se eliminarán con sus padres, otros recursos como las fuentes deben liberarse manualmente o registrarse como un receptor de disposición para un componente para la liberación automática.
josefx
fuente
33
Swing estará más cerca de "escribir una vez, correr en cualquier lugar". SWT será más como "escribir una vez, ajustar / probar en todas partes". Pero esta misma discusión ocurrió con otros idiomas también.
Mark
12
Siendo realistas, el aspecto "nativo" de Swing se comporta de manera muy diferente a mi escritorio Gnome, mientras que, por alguna razón, los temas funcionan bastante bien, los menús se ven horribles y son casi inutilizables.
Hut8
9
Comenzando con Eclipse 3.7, VEP fue reemplazado por WindowBuilder (que también admite Swing y SWT).
Alexey Romanov
66
La ventaja de SWT también es menos consumo de memoria debido a los componentes nativos. Esto debería ser deseable en máquinas con memoria limitada y las diferencias de memoria entre swing y swt pueden ser grandes en diseños de GUI grandes.
jantobola
1
@ JanTobola Está completamente equivocado. Los componentes nativos usan memoria asignada en el montón nativo, no solo en el montón Java. He trabajado en grandes interfaces gráficas de usuario utilizando Netbeans Platform, Eclipse RCP, SWT y Swing. Hubo algunas preocupaciones serias sobre la huella de memoria en Swing en las primeras versiones de Java (cuando era una biblioteca de terceros y también de 1.1 a 1.2). ) pero ya no es cierto y depende de los desarrolladores liberar muchos recursos en SWT, hay muchas más oportunidades de pérdida de memoria con SWT, mientras que un componente sin referencia termina siendo "eliminado" con Swing.
gouessej 01 de
63

Una cosa importante a tener en cuenta es que algunos usuarios y algunos revendedores (Dell) instalan una máquina virtual de 64 bits en su Windows de 64 bits, y no puede usar la misma biblioteca SWT en máquinas virtuales de 32 bits y 64 bits.

Esto significa que necesitará distribuir y probar diferentes paquetes dependiendo de si los usuarios tienen una máquina virtual Java de 32 o 64 bits. Vea este problema con Azureus, por ejemplo, pero también lo tiene con Eclipse, donde a partir de hoy las compilaciones en la página de descarga frontal no se ejecutan en una máquina virtual de 64 bits.

Ludovico Fischer
fuente
2
Punto interesante Como usuario, todavía estoy asombrado de por qué esto es tan importante. Pero bueno, es así que tendré que considerar esto. Gracias.
janpio
por cierto: javaws (webstart) no está disponible para 64 en mi humilde opinión
Karussell
1
@Karussell: A partir del 4/03/2011, la JVM de 64 bits de Sun para Windows tiene soporte JNLP. Creo que ha sido cierto por un tiempo, pero no estoy seguro de cuánto tiempo.
The Alchemist
23

swing profesional:

  • La mayor ventaja de swing IMHO es que no necesita enviar las bibliotecas con su aplicación (lo que evita docenas de MB (!)).
  • La apariencia nativa es mucho mejor para el swing que en los primeros años
  • el rendimiento es comparable a swt (¡el swing no es lento!)
  • NetBeans ofrece a Matisse como un generador de componentes cómodo.
  • La integración de los componentes Swing dentro de JavaFX es más fácil.

Pero en el fondo no sugeriría usar swing 'puro' o swt ;-) Hay varios marcos de aplicación para swing / swt out. Mira aquí . Los jugadores más importantes son netbeans (swing) y eclipse (swt). Otro buen marco podría ser el grifo y un buen 'conjunto de componentes' es el pivote (swing). Griffon es muy interesante porque integra muchas bibliotecas y no solo swing ; también pivote, swt, etc.

Karussell
fuente
1
Sí, NetBeans tiene a Matisse como un generador de GUI, pero el código es realmente detallado, confuso de leer y casi imposible de editar por código fuente. Si realmente quieres un generador de GUI, ve con eclipses WindowBuilder
Pranav A.
13

Usaría Swing por un par de razones.

  • Ha existido por más tiempo y se le ha aplicado más esfuerzo de desarrollo. Por lo tanto, es probable que tenga más funciones completas y (tal vez) tenga menos errores.

  • Hay mucha documentación y otras pautas para producir aplicaciones de alto rendimiento.

  • Parece que los cambios en Swing se propagan a todas las plataformas simultáneamente, mientras que los cambios en SWT parecen aparecer primero en Windows, luego en Linux.

Si desea crear una aplicación con muchas funciones, puede consultar el RCP de NetBeans (Plataforma de cliente enriquecido). Hay una curva de aprendizaje, pero puedes juntar buenas aplicaciones rápidamente con un poco de práctica. No tengo suficiente experiencia con la plataforma Eclipse para hacer un juicio válido.

Si no desea usar todo el RCP, NetBeans también tiene muchos componentes útiles que se pueden extraer y usar de forma independiente.

Otro consejo: busca en diferentes gerentes de diseño. Me hicieron tropezar durante mucho tiempo cuando estaba aprendiendo. Algunos de los mejores ni siquiera están en la biblioteca estándar. Las herramientas MigLayout (tanto para Swing como SWT) y JGoodies Forms son dos de las mejores en mi opinión.

clartaq
fuente
10

Elegiría swing solo porque es "nativo" para Java.

Además, eche un vistazo a http://swingx.java.net/ .

a cero
fuente
1
¡El enlace está roto!
Sócrates
8

Para sus requisitos, parece que la conclusión será usar Swing, ya que es un poco más fácil comenzar y no está tan integrado a la plataforma nativa como SWT.

Swing generalmente es una apuesta segura.

Yuval Adam
fuente
6

Interesante pregunta. No conozco SWT demasiado bien para presumir (a diferencia de Swing y AWT), pero aquí está la comparación realizada en SWT / Swing / AWT.

http://www.developer.com/java/other/article.php/10936_2179061_2/Swing-and-SWT-A-Tale-of-Two-Java-GUI-Libraries.htm

Y aquí está el sitio donde puede obtener tutoriales sobre básicamente cualquier cosa en SWT ( http://www.java2s.com/Tutorial/Java/0280__SWT/Catalog0280__SWT.htm )

Espero que tome una decisión correcta (si hay decisiones correctas en la codificación) ... :-)

Buhake Sindi
fuente
44
Pero tenga en cuenta que el artículo es de 2003 ...
Alexey Romanov
4

Si planea crear aplicaciones funcionales completas con más de un puñado de características, le sugiero que salte directamente al uso de Eclipse RCP como marco.

Si su aplicación no crecerá demasiado o sus requisitos son demasiado únicos para ser manejados por un marco comercial normal, puede saltar con seguridad con Swing.

Al final del día, te sugiero que pruebes ambas tecnologías para encontrar la que más te convenga. Al igual que Netbeans vs Eclipse vs IntelliJ, no existe la respuesta correcta absoluta aquí y ambos marcos tienen sus propios inconvenientes.

Pro Swing:

  • mas expertos
  • más parecido a Java (casi sin campo público, no es necesario disponer de recursos)

SWT profesional:

  • más sistema operativo nativo
  • Más rápido
nanda
fuente
10
Creo que el punto "más rápido" es muy polémico.
Russ Hayward
SWT es engorroso de usar, tuve que probar mi GUI con cada versión de Windows, algunos errores solo se podían reproducir en Windows Vista. Algunos métodos simplemente no se implementan o llaman a AWT debajo del capó, lo que significa que no puede usar un JRE compacto sin AWT y Swing sin arriesgarse a romper SWT. Comencé a usar SWT en 2009 y, en mi humilde opinión, no es más rápido. Le aconsejo que proporcione un punto de referencia cuidadosamente diseñado.
gouessej 01 de
4

Una cosa a considerar: lectores de pantalla

Por algunas razones, algunos componentes de Swing no funcionan bien cuando se usa un lector de pantalla (y Java AccessBridge para Windows). Sepa que diferentes lectores de pantalla resultan en un comportamiento diferente. Y en mi experiencia, el SWT-Tree funciona mucho mejor que el Swing-Tree en combinación con un lector de pantalla. Por lo tanto, nuestra aplicación terminó usando componentes SWT y Swing.

Para distribuir y cargar la biblioteca SWT adecuada, puede encontrar útil este enlace: http://www.chrisnewland.com/select-correct-swt-jar-for-your-os-and-jvm-at-runtime-191

incomudro
fuente
3

SWT fue creado como respuesta a la lentitud de Swing a principios de siglo. Ahora que las diferencias en el rendimiento se están volviendo insignificantes, creo que Swing es una mejor opción para sus aplicaciones estándar. SWT / Eclipse tiene un marco agradable que ayuda con mucho código de placa de caldera.

Oliver Watkins
fuente