¿Comienza a migrar su proyecto Swing a JavaFX [cerrado]

Tengo un proyecto de 4 años que está escrito en Swing + SwingX. Actualmente, todavía está vivo y sigue pateando.

Sin embargo, a medida que llegan más solicitudes de funciones relacionadas con la GUI (por ejemplo, una tabla de árbol ordenable), empiezo a sentir la dificultad de completar las solicitudes. Esto es cierto especialmente porque no hay ningún desarrollo activo en torno al proyecto SwingX.

Además, difícilmente puedo encontrar un buen marco de Java GUI que se mantenga / desarrolle / desarrolle activamente.

Me preguntaba, ¿alguno de los desarrolladores de Swing siente lo mismo? ¿Has comenzado a migrar tu proyecto Swing a un marco GUI desarrollado mucho más activo, como JavaFX?

Personalmente, me mudaré a JavaFX (2.1+, no la antigua versión 1.x extraña con el desagradable lenguaje de scripting). El nuevo JavaFX no es 100% perfecto, pero ya es mucho más agradable de usar que Swing, veo un futuro razonable para él (especialmente dado el motor Webkit incorporado).

A menudo me pregunto lo mismo, pero no creo que migre proyectos existentes a JavaFX. Al menos no por ahora, y no para proyectos de mediano a gran tamaño. Sin embargo, consideraría JavaFX para nuevos proyectos, y consideraría una migración nuevamente en el futuro y volvería a evaluar la pregunta basada en el progreso de JavaFX.

Por el momento, mis preocupaciones son:

• Inmadurez

  Sí, pronto iremos a 3.0, pero no ha existido por tanto tiempo y aún ha pasado por cambios importantes. Entonces, para el software corporativo grande y con aversión al riesgo, este es un lugar relativamente doloroso.

• Actuación

  No he visto suficientes datos sobre diferencias de rendimiento.

• Widgets y Componentes

  No he visto suficiente ganancia en los nuevos componentes. Esto puede relacionarse con la inmadurez, supongo. Tampoco sé aún qué tan bien se pueden extender y componer, en contraste con Swing.

En general, supongo que los datos duros sobre las ventajas son lo que me falta para que JavaFX los convenza por completo.

Por otro lado, Swing está probado y probado. Sí, la API es torpe e invoca la finalización automática en su IDE en un objeto Swing como el JTextPane lo hará llorar y llorar por su mami, pero, si tiene suficiente conocimiento, puede construir interfaces de usuario impresionantes con Swing, eso están funcionando bien (nunca compré la falacia de Swing-has-bad-performance, vea las publicaciones de blog anteriores de Romain Guy en los blogs de Sun) y le permiten hacer cosas bastante buenas.

Entonces, antes de cambiar cualquier cosa, te recomiendo que pruebes primero un pequeño prototipo, y tal vez intentes portar algunos de los cuadros de diálogo de tu aplicación y ver cómo funciona.

He estado haciendo mucho JavaFX ahora y lo prefiero a Swing. La estructura del gráfico de escena es diferente a la que estás acostumbrado con Swing, pero proporciona muchas mejoras. Es divertido trabajar con la API, se siente refrescante.

Hay mucho más que puedes hacer con él, multimedia, animación, navegación web. Por ejemplo, puede crear una aplicación de Google Maps en unas pocas líneas de código, incorporando html5 y javascript.

Se dice que está incluido en el tiempo de ejecución de Java 8, lo que significaría como el reemplazo definido de Swing como el marco ui predeterminado

@ Migración : debe comenzar aislando partes de su aplicación que se pueden convertir a JavaFX. La interoperabilidad Swing-JavaFX 2 es una gran cosa, puede usar javafx.embed.swing.JFXPanel para incrustar su elemento JavaFX. Ver swing-fx-interoperability . (Para completar, también puede incrustar en SWT).

Swing se está convirtiendo en una tecnología heredada, o ya lo es. Sin embargo, es bastante bueno en lo que hace y no va a desaparecer en un futuro previsible, por lo que no veo ninguna razón para alejarse de él, especialmente si ya ha invertido en él. El software JIDE hace buenos componentes (comerciales) de Swing para reemplazar lo que falta en el Swing estándar. Por ejemplo, se puede ordenar TreeTable está en sus rejillas de la caja.

Si bien las nuevas versiones de JavaFX se ven muy impresionantes, dudo que valga la pena realizar una migración completa a menos que esté dispuesto a invertir mucho tiempo / esfuerzo / dinero en una revisión completa de la GUI.

Swing puede tener sus peculiaridades y está mostrando su edad, pero también tiene algunas ventajas:

• Capacidad multiplataforma muy fuerte, actualmente mucho mejor que JavaFX
• Es maduro y probado, mucho más que JavaFX
• Tiene una gran comunidad de usuarios / ecosistema de bibliotecas.
• Probablemente ya tenga muchas habilidades de Swing o pueda contratar personas fácilmente con ellas.

En definitiva, si no está roto, ¿por qué arreglarlo?

Por supuesto, para un nuevo proyecto, estaría mirando muy en serio JavaFX, Android y / o una GUI basada en la web (quizás con algo como Vaadin).

Estoy en la misma posición que el OP: tengo aplicaciones de swing heredadas pero necesito implementar nuevos modismos e interfaces que no admite de forma nativa. La mayor de estas aplicaciones ha sido refactorizada un par de veces por varias razones (mejorar la modularidad, mejor MVC y estructura de envío de eventos, etc.) por lo que no estoy completamente reacio a reescribir el código de la interfaz de usuario. Así que he pensado mucho sobre el tema.

Sin embargo, algunas cosas no se pueden resolver con Swing sin invertir mucho más tiempo y esfuerzo en lo que es esencialmente una tecnología heredada. Por ejemplo, aparte de los simples eventos del mouse, los nuevos dispositivos de pantalla táctil y Swing no son compatibles. Proporcionar un componente de navegador basado en Swing es igualmente problemático o costoso, y en mi caso, el enfoque javafx-in-swing no es una opción, ya que complica el manejo de eventos de IU de maneras no triviales.

Creo que ha sido antiguo y fiel en su tiempo, y si su plataforma es tan inmutable como su código base, quédese con ella, obviamente. Pero para que una aplicación avance a nuevos casos de uso más contemporáneos, JavaFX 2+ probablemente sea la forma de avanzar en mi caso.

Como nota al margen: la única característica errónea en Swing que me hubiera encantado haber desaparecido en jfx, pero no lo hice, es el enfoque de un hilo para gobernarlos a todos para el envío de eventos de UI. Cualquier interfaz de usuario no trivial necesita múltiples subprocesos para mantener la interfaz de usuario nítida y receptiva, y dejar que el desarrollador de la aplicación pueda tropezar con los mismos escollos tan fácilmente es un déficit en la API en mi humilde opinión.

He tenido una gran experiencia usando RCP en grandes aplicaciones basadas en escritorio. Básicamente comenzó como una abstracción de la capa GUI de Eclipse y ha recorrido un largo camino desde entonces. En lugar de Swing, que se basa en AWT, RCP se basa en JFace, que a su vez se basa en SWT. Le permite desarrollar aplicaciones y usar los conceptos de GUI que usa Eclipse (vistas, editores, perspectivas, asistentes, etc.). Es muy escalable y, al igual que Eclipse, se mejora constantemente.

Sin embargo, nunca he migrado un proyecto existente de Swing a RCP; Me imagino que tomaría bastante tiempo comprender los diferentes paradigmas y si no ha separado bien su modelo y las capas de visualización, seguramente lo pasará mal. Pero como preguntaste sobre cosas como tablas de árbol ordenables, RCP es excelente en eso.

Si desea profundizar más en esto, puede probar el tutorial de Lars Vogel o echar un vistazo a algunos ejemplos de proyectos de código abierto o proyectos comerciales que utilizan RCP.

(Por ejemplo, una tabla de árbol ordenable), empiezo a sentir la dificultad de completar las solicitudes. Esto es cierto, especialmente porque no hay un desarrollo activo en torno al proyecto SwingX.

• no es cierto, nuevamente este proyecto está vivo,

• blablabla una vez cuando SwingX perdió las subvenciones de Sun (durante la adquisición por parte de Oracle) los pueblos de SwingX fueron a JavaFX construido

Además, casi no puedo encontrar nada bueno, sin embargo, estoy siendo mantenido / desarrollado / evolucionando activamente el marco de Java GUI.

• no Swing no se trata de Framework sino de Look and Feel

• Los marcos son para usuarios no técnicos (MsAccess puede ser el mejor ejemplo para el marco GUI)

• pero si desea crear una aplicación real, también tiene fuertes conocimientos sobre Swing y la anulación de Framework,

• ejemplo divertido Netbeans ha incorporado un marco Swing basado en JSR296, pero no puede cambiar el icono JFrames directamente,

¿Has comenzado a migrar tu proyecto Swing a un marco GUI desarrollado mucho más activo como JavaFX?

no hay razón por qué

• lo mismo con la migración a Java7, tal vez cuando estará allí Java7.15 - 17

• Comparo JavaFx con el Nimbus, el desarrollo terminó / abandoné en algún momento de la primera mitad

• lo siento, no soy desarrollador, solo soy Java & Swing Fan