¿Qué inconvenientes tiene el framework Java Swing GUI? [cerrado]

He usado Java Swing para algunas aplicaciones de escritorio. Pero no he usado otros frameworks GUI tanto que no puedo compararlos.

Definitivamente hay algunas cosas que me gustan con Swing y otras que no me gustan, pero esa es la situación con casi todo.

¿Cuáles son los mayores inconvenientes con el marco Java Swing GUI?

frameworks gui swing

— Jonas
fuente

La pregunta es interesante. También me pregunto cuáles son las fortalezas y debilidades de Swing, en comparación con QT, GTK, SWT, Winforms, Cocoa y similares. Tal vez debería reformular el título de pedir comparaciones , en lugar de inconvenientes (que tienden a dar respuestas no están bien argumentadas)

— Barjak

Respuestas:

Tienes que tener Java instalado en alguna parte. Esto es cierto para todos los marcos de GUI, por supuesto, pero Java tiene la percepción de un gorila de 2 toneladas. Se ha mejorado muchísimo, pero esos primeros días de applets de Java apagaban a mucha gente. Si solo lo necesita para ejecutar su única aplicación, es mucho mantenimiento mantenerla actualizada con parches de seguridad y similares. Todos deben tener Flash para YouTube, .Net Framework se instala detrás de escena y todos tienen habilitado JavaScript en su navegador. Java suele ser una cosa extra que hacer.
A pesar de que es algo así como escribir una vez, ejecutar en cualquier lugar, todavía encuentra que Mac OSX no tiene esta nueva cosa que desea usar o un cliente se niega a actualizar su mandrake linux más allá de JRE 1.4.
Como desarrollador, debes pensar en enhebrar. Y es complicado, ya que es posible el subprocesamiento múltiple, pero el swing simula que todo es de un solo subproceso. Pero luego, la mitad de las bibliotecas que utiliza tienen cierto grado de subprocesamiento múltiple y asumen que conoce EDT invokeLater y obliga a muchas lecciones de la manera difícil.
La experiencia de Swing no se transfiere fácilmente a otros tipos de desarrollo de UI. Por ejemplo, si eres un genio en las tablas en .css, Jtables, renderizadores, editores, etc.

En general, el principal problema con Swing es que no estuvo a la altura de cómo se comercializó. Es una tecnología perfectamente adecuada para muchos casos de uso, pero esos primeros 5 o 6 años estuvieron llenos de implementaciones terribles y applets atroces. Y ahora es tecnología antigua: la Web 3.0 o lo que sea.

Dicho todo esto, me gusta Swing y creo que los profesionales generalmente superan a los contras cuando necesitas lo que ofrece. Sin embargo, la experiencia web es tan omnipresente ahora que muchos usuarios van a tener más facilidad con una aplicación web que con la aplicación de swing increíble más optimizada. Y hay increíbles aplicaciones de Swing, pero no parecen ser convencionales.

— Steve Jackson
fuente

Estoy en la misma situación que el OP: conozco Swing y estoy interesado en compararlo con otras tomas de GUI. Para mí, los puntos 1, 2 y 4 son irrelevantes para la pregunta. Entonces, me gustaría reaccionar al punto 3: ¿podría dar algunos ejemplos de kits de herramientas GUI multiproceso? Gracias.

— barjak

@barjak: la GUI multiproceso es un error. El único que conozco es el viejo Java AWT. Pero aprendieron de los errores cuando diseñaron Swing, que tiene un solo subproceso como todos los marcos de GUI modernos.

— Jonas

@Jonas Hacer que un desarrollador piense en subprocesos múltiples a menudo es un error, pero no puede ejecutar animaciones, realizar llamadas RMI o hacer cálculos intensos (este es un kit de herramientas de cliente pesado, recuerde) sin cierto grado de subprocesamiento múltiple.

— Steve Jackson

@ Steve: Eso es cierto. Sin embargo, usted debe no hacer llamadas RMI y cálculos intensos en la GUI-hilo. Ese tipo de cosas debe hacerse en un hilo de fondo, como en Swing y WPF.

— Jonas

@barjak: formularios de Windows, MFC, SWT, pyQT, Juce ... Me resulta más difícil pensar en los que no son multiproceso. Sin embargo, las mismas reglas generalmente se aplican, no puede tocar los componentes de su GUI excepto desde el hilo que los creó.

— Steve Jackson

Jonas

Swing generaliza su arquitectura subyacente para brindarle una experiencia de usuario neutral en la plataforma. El único componente de peso pesado (proporcionado por el sistema operativo) es el contenedor JFrame y el resto es manejado por Swing takeit. AWT, por otro lado, le pide al sistema operativo que dibuje todos sus componentes de la interfaz de usuario, lo que significa que es más rápido de muchas maneras a medida que usa los componentes de la interfaz de usuario nativos específicos del sistema operativo. SWT intenta alcanzar un punto medio, para varios componentes estándar como botones y etiquetas (que están disponibles en la mayoría de los sistemas operativos), permite que el sistema operativo se ocupe de esos y para otros componentes especializados, SWT se encargará de la creación por usted.

Dicho esto, puedo describir los inconvenientes.

(1) Dado que el kit de herramientas crea y renderiza los componentes por usted en lugar de preguntarle al sistema operativo, no puede aprovechar la velocidad de los componentes integrados proporcionados por el sistema operativo.

(2) La interfaz de usuario no es particularmente perjudicial, ya que se ve ajena a la mayoría de las plataformas del sistema operativo en lo que respecta a la apariencia que usa.

(3) Algunos de los administradores de diseño, es decir, GridBadLayout, etc., podrían simplificarse mejor. He perdido la cuenta de la cantidad de proyectos en los que he trabajado en los que la gente ha incluido GridBagLayout en un código a medida para obtener una forma más sencilla de usarlo.

Le aconsejo que escriba una aplicación simple en AWT, Swing y SWT y compare los enfoques de desarrollo y el producto final entre todos, luego revise los diversos comentarios hechos por otros desarrolladores y decida cuál funciona mejor. He trabajado con Swing durante muchos años y solía disgustar SWT, pero me di cuenta de que Swing es mucho más complicado de lo que debería ser en comparación con otros marcos existentes.

— Planeta desolado
fuente

Swing es acelerado por GPU , lo que los frameworks nativos no son frecuentes, por lo que creo que Swing es más rápido. Esta es también la estrategia que tiene WPF en Windows pero no WinForms (solo en algunas versiones de Windows). ¿Cómo puede ser cierto "[feo] ... respecto de la apariencia que usa" cuando es muy personalizable o puede usar las plataformas propias de LaF? Estoy de acuerdo en que los gerentes de diseño son realmente malos.

— Jonas

Jonas, es el aspecto "personalizable" del swing lo que lo hace complicado en comparación con otros frameworks. Si intenta abstraerse de las funciones que le ofrece el sistema operativo, pierde muchos de los beneficios que ofrece. La primera versión de Swing fue una pesadilla, lo que llevó a la creación de SWT en primer lugar. Más tarde, Swing se mejoró para ser mucho más rápido y tienes clases como SwingUtilities que ofrecen un mejor soporte de subprocesos para las GUI.

— Desolate Planet

Feo podría ser la palabra equivocada; alien podría ser una mejor palabra, ya que la apariencia no es exactamente la misma que la apariencia de la interfaz de usuario nativa, por lo que recuerdo, tienes Java, motivo, metal y algunos otros, pero en general, no lo son t todo eso bonito.

— Desolate Planet

El siguiente aspecto a tener en cuenta cuando se hace una comparación es el esfuerzo realizado para desarrollar una IU. No diría que los gerentes de diseño son realmente malos, es mejor que ningún diseño (que tengo que tratar en el trabajo en un dispositivo móvil), pero no hacen ningún esfuerzo para simplificar el modelo.

— Desolate Planet

Creo que, según lo que ha dicho, ha estado utilizando la versión más reciente de Swing, pero cuando salió por primera vez, a la gente le disgustó mucho y aún más cuando intentaron proporcionar applets basados en Swing. Hay muchos antecedentes de los marcos de interfaz de usuario desarrollados en Java y es una lectura interesante si lo miras.

— Desolate Planet

-2

El swing es lento (mal rendimiento), difícil / torpe de usar (en comparación con muchos otros) y no se ve muy bien, de hecho muy mal, en algunas plataformas.

— Anto
fuente

Lo encuentro rápido (tiene aceleración de GPU, en comparación con muchas GUI nativas), así que no puedo estar de acuerdo con el rendimiento o ¿tiene algún ejemplo? ¿Cómo es difícil y torpe en comparación con otros marcos? Estoy de acuerdo en que no se ve bien, pero se puede configurar para que parezca aplicaciones nativas o usar un LaF personalizado.

— Jonas

Parece más o menos no nativo en GTK. Lo que he escuchado es que, dado que se basa en Java 2D para dibujar widgets, es lento, pero no tengo nada con qué demostrarlo. Tanto Qt como GTK me parecen menos torpes, pero los gustos difieren.

— Anto

Ah, puede funcionar peor en algunas plataformas. Solo lo he usado en Windows, donde es acelerado por GPU y muy rápido.

— Jonas

La gente todavía se queja de que algo no parece nativo, mientras usa más y más cosas del navegador (piense: stackexchange), ¿dónde cada página se ve diferente? Y la velocidad? La mayoría de las veces, un programa GUI interactivo está esperando al usuario.

— Usuario desconocido

La mayoría de los programas "de moda" ya no parecen nativos. El swing no termina mejor ni peor en ese sentido. El rendimiento de nuestra aplicación de swing 50kloc (cliente gordo) parece estar bien. Mucho más fácil conseguir el swing hasta el punto de no bloquearse que las aplicaciones "nativas".

— Tim Williscroft