¿Está Oracle malgastando su tiempo con Java FX?
Abraham
Muchas son las críticas que se le puede hacer a Java FX. El llegar tarde a un nicho ya muy copado por otras tecnologías. El haber empezado con mal pie (Java FX 1.0). Pero al margen de esto ¿tiene sentido una tecnología como Java FX en la era del HTML 5?. Cada vez hay más señales que apuntan a que no.
Analicemos el caso del "gorila de 500 kilos" en el nicho en el que Java FX se está intentando introducir: Flash/Flex. La semana pasada conocíamos que Adobe abandonaba el desarrollo de Flash para dispositivos móviles, y anunciaba que centraría el desarrollo de su plataforma en:
“focusing Flash resources on delivering the most advanced PC web experiences, including gaming and premium video”
A la vez, la compañía anunciaba un despido de 750 empleados (en torno a un 10% de toda su plantilla) en todo el mundo. Y sus acciones caían fuertemente. Un claro síntoma de que Adobe ha vivido tiempos mejores que los que está viviendo. La causa de esta "crisis del Flash" está bastante clara: HTML 5. Mucha de la funcionalidad que ahora se conseguía a través de Flash ahora puede conseguirse en HTML. Y cada vez las cosas se moverán más en esa dirección. Por eso la compañía afirma que ahora se va a centrar en "las experiencias más avanzadas", es decir, en aquellas cosas que todavía no hace (al día de hoy) a HTML 5. Pero cada vez HTML 5 proporcionará más funcionalidad recortará más los casos en los que Flash proporciona más funcionalidad.
El otro competidor de Java FX es Silverlight. Una tecnología que al igual que Java FX llegó tarde, y que a pesar de todo el músculo de Microsoft no terminó de despegar. Al final de la semana pasada conocimos una serie de rumores apuntando hacia que Silverlight 5.0 será la última versión de Silverlight y que el propio Microsoft se centrará en HTML 5 para el desarrollo de aplicaciones RIA.
Volviendo a Java FX ¿tiene sentido que Oracle emplee su tiempo y recursos en desarrollar una tecnología que pretende reemplazar/competir con otras tecnologías que parecen estar en camino hacia su extinción? ¿Tendría más sentido para Oracle centrarse en proporcionar herramientas a los programadores Java para trabajar con HTML 5 en vez de emplear recursos en una tecnología que al menos en ciertos aspectos es competidora de HTML 5?.
Quizás esto último es precisamente el propósito del proyecto Avatar que se presentó en esta última Java One, proyecto que nadie sabe en qué consiste. Lo único que se sabe es que "tiene que ver con HTML 5". Pero nadie le ha quedado en absoluto claro exactamente qué es.
Al margen de las bondades y deficiencias de la tecnología (como el hecho de que todavía no correr en Linux...) ¿creéis que tiene sentido la estrategia general de Java FX o tendría más sentido unirse al carro de HTML 5? Hagamos una pequeña encuesta para ver la opinión de la comunidad sobre este tema:
Reader Comments (25)
Copio de los comentarios del formulario:
JavaFX no solo es una tecnologia para competir con Flash, sino que tambien sirve llevar realmente java al mercado de las aplicaciones de escritorio. Ademas HTML5 tiene muchas deficiencias para hacer aplicaciones complejas como puede ser una comunicacion del servidor al cliente o el uso de hilos.
Ademas JavaFX aumentara enormemente el soporte de HTML5 en aplicaciones de escritorio java al tener un browser como tal.
Por cierto, Oracle quiere que JavaFX sea open source, lo cual reducira notablemente el presupuesto que tengan que dedicar a esa tecnologia
A mi me parece un movimiento interesante. En principio, la idea es matar dos pájaros de un tiro. Mejoran las aplicaciones de escritorio visualmente y reducen el tiempo de desarrollo.
Por otro lado, el proyecto de generación de HTML5 puede llegar a competir con toolkits como GWT o Vaadin (no sé muy bien cómo quieren abordar el tema, así que puede estar bastante abierto).
Yo lo sigo bastante de cerca para ver cómo evoluciona.
Desde mi punto de vista, JavaFX no está peleado con HTML 5 ni creo que pretenda sustituirlo de alguna manera, por el contrario, creo que piensa complementarse con HTML5.
Otro de los factores importantes de JavaFX es la visión de utilizarlo como estándar para las aplicaciones de escritorio ya sea en modo "stand alone", o mezclado con las hasta hoy en día intefaces Swing.
Sin embargo, creo que Oracle podría tener su santo grial con JavaFX si lograra realizar una alta interoperabilidad con HTML 5, es decir, que para el desarrollador fuera transparente realizar una App JavaFX que pueda correr tanto en el escritorio como en un navegador mediante incrustación (salvando las deficiencias de los clásicos Applets) o hacer algo similar a lo que Microsoft pretende realizar con XAML en .Net: un lenguaje común para describir interfaces visuales de usuario que pueden correr tanto en el escritorio como dentro de un navegador web.
Saludos!
Java FX efectivamente tiene alguna funcionalidad más que HTML 5. Pero HTML 5 cubre ya la mayor parte de los casos de uso típicos. Y cada vez va a cubrir más. Cada vez el porcentaje de aplicaciones donde Java FX podría tener sentido por tener más funcionalidad va a ser menor. Y esa funcionalidad extra se consigue con el coste de requerir que el usuario tiene instalado un plugin. Desde mi punto de vista, en la inmensa mayoría de los escenarios lo que aporta no va a compensar. Prueba de ello es lo que le está pasando a Flash.
Y respecto al tema de que es opensource, eso no garantiza que haya contribuciones. Netbeans y Glasfish son buena prueba de ello. Dos proyectos que lleva muchos años siendo opensource y para los cuales prácticamente sólo contribuye Oracle.
Personalmente?
Independientemente de lo que Oracle quiera hacer con JavaFX, la verdad es que cada vez más se hace urgente un mantenimiento evolutivo dentro de la infraestructura ya existente (Graphics2D, AWT, Swing). So pena de quedar definitivamente fuera del juego.
Rasgos como layout animados y autofocales, multitouchscreen, embeber browser, u otras características avanzadas, que pueden verse en las interfaces de última generación (incluyendo los navegadores) deberían estar presentes en Swing para que escalen naturalmente a la infraestructura (y los miles de aplicaciones) ya existentes.
El riesgo, no es que Oracle siga perdiendo el tiempo con JavaFX, el riesgo es que no atienda las necesidades de Swing, para la nueva generación de interfaces visuales en los SO's.
Sin mencionar, ampliar la base de SO soportados por JSE.
Un salido.
Eduardo, Oracle ha dicho bastante claramente que no va a continuar evolucionando swing. Swing es una tecnología "legacy", como AWT. El futuro es Java FX, o eso dicen ellos.
Precisamente, tal y como dice efrigerio, el futuro de Swing está, en estos momentos, tan ligado al de JavaFX, que un fracaso de este último podría suponer la obsolescencia a perpetuidad del primero.
Si, como se pretende, van a tardar alrededor de 4 años, como mínimo, en integrar JavaFX en el JDK, que creo que es la condición indispensable para que la transición de Swing al nuevo JFX se pueda realizar con plenas garantías, o bien JFX tiene éxito, o se hunden ambos, JFX y Swing.
Y no tiene nada que ver con lo que se pueda hacer en clientes web, en relación con HTML5.
La inmensa mayoría de aplicaciones Swing son de escritorio, y en su inmensa mayoría también de uso empresarial e industrial, con excepciones notables, tales como Vuze y LimeWire.
Si Oracle falla en su apuesta por substituir Swing por JFX, los más perjudicados serán sus principales clientes, y los clientes de todas las corporaciones que están haciendo una piña alrededor de Java, que son los principales desarrolladores en Swing.
Visto desde esta perspectiva, se entienden las prisas recientes por mover JavaFX a Open Source, y por integrarlo en el JDK cuanto antes: así se implica a todos los que ya están en el OpenJDK.
O puede ser más bien al revés, que sean las demás corporaciones las que presionan a Oracle, para que sus productos y desarrollos en Swing mantengan la competitividad que pierden por su cuasi obsolescencia.
Hola Abraham,
Y hasta que JavaFX esté a la altura.
¿ Que tienen que hacer NetBeans Platform, Spring- RCP, y todos los demás?
¿Qué pasa con los nuevos proyectos y Windows Metro (Windows 8 para ARM)?
Si Oracle, SAP, IBM y el resto de las empresa de primera línea que viven de java no resuelven esto con prontitud, pues entonces he de darte la diestra y decir que Java, cada día se parezca mas a Cobol.
Un saludo.
te recuerdo escritor que oracle tiene tecnologias para web como ADF un framework talvez el mas avanzado del mercado , en web sin java fx!
@choces
El problema es que no tenemos esos 4 años, estos rasgos se necesitan desde ayer.
Y como bien dices tampoco tiene nada que ver con lo que se pueda hacer en clientes web
Estamos pagando los años perdidos en el desarrollo de ese "invento" de JavaFX 1.x
Mientras la gran mayoría de desarrolladores le daba la espalda, con razón, Swing se quedó como la "pariente pobre", a quién solo se le daba la "limosna" de mantenerlo lo más libre de bugs posible; pero sin invertir apenas recursos en su mejora.
Aún así, se colaron gloriosas meteduras de pata, como la de SwingWorker en la versión 1.6.14 ó 15 (no recuerdo bien), que convirtieron a Swing de golpe en "monotarea"; para arreglarlo al poco tiempo con un Executor interno limitado a 10 tareas simultáneas, como está en la actualidad.
La "política" habitual de SUN, el famoso "not invented here", ha hecho mucho daño con respecto a las mejoras que se reclamaban desde hace años; y no veo que Oracle haya cambiado significativamente esa política. A excepción de abrirles las puertas a otras corporaciones, que tampoco tienen una "política" al respecto muy diferente.
A pesar de que se quiere presentar cualquier tontería como la "gran innovación del año", lo triste es que la verdadera innovación se hace, como se ha hecho siempre, quemando las pestañas propias, a base de extender interminablemente las clases "estándar" de Swing, y de lo que no es Swing, para obtener una mínima funcionalidad aceptable.
Tienes toda la razón en que no tenemos no ya 4, sino ni 1 año siquiera que perder.
Lamentablemente me temo que sus "tiempos" son otros.
Me contentaria que JavaFX estuviera el nivel de QT,swing esta bastante obsoleto,todavia no han cambiado el uso interno de vector por linkedlisto o arraylist,no soportan genericos,mal comportamiento multihilo,ni hablar de AWT,que carece de acceleracion grafica,me contentaria si copiaran muchas cosas de QT(soporta multimedios,animaciones 2D y 3D ,como unir versiones actualizadas de JMF,Java3D y otros proyectos).
Claro seria un plus si es compatible con lambdas y closure de Java 8.
@JP
Desde Java 1.7 se pueden usar genéricos tanto en JList<E> como en JComboBox<E>; y siempre se ha podido crear un model, para cualquiera de ambos, que use List<E>.
Swing no se comporta mal en multitarea, aunque use internamente una única tarea. Lo que sí es cierto es que manejar tareas paralelas, junto con el EDT, sin que haya problemas, puede llegar a ser bastante complicado.
Ejemplos de lo que se puede llegar a hacer con Swing:
Steel Series Demo: http://idisk.mac.com/han.solo-Public/SteelSeries/test.jnlp
Tomado de esta página, que es una joya:
http://harmoniccode.blogspot.com/
Un par de enlaces bastante interesantes, choces
Sí, Abraham, por eso aproveché el comentario para hacer referencia a ellas.
Como esas hay muchas, que llevan demostrando desde hace años, que no es Swing todo lo que reluce en el JDK.
A eso me refería con "quemarse las pestañas propias", en un comentario anterior.
Swing tiene "mala prensa" porque se suele creer que lo único que existe es lo que "va de serie" con el JDK de turno. La realidad es que hay toneladas de código en Swing, que llevan muchos años extendiéndolo, con diversa fortuna, y que han sido ignorados sistemáticamente.
Si algo así se puede realizar en Swing, imagina lo que se podría hacer con un JFX, liberado de una vez de las limitaciones del AWT.
Buenos días.
En mi humilde punto de vista me parece muy interesante la creación de JavaFX pero por otro lado considero que en lugar de invertir en una nueva tecnología sería mejor trabajar en modernizar y optimizar lo existente. Yo soy un usuario de swing. Tengo más de 7 años trabajando con swing y considero que es una muy buena herramienta. He podido hacer muchas cosas interesantes con swing. Lo malo es que para hacer esas muchas cosas interesantes he tenido que hacer una serie de cosas que podrían haber sido incorporadas al lenguaje. Yo considero que JavaFX podría haber sido una mejora de swing y no un nuevo producto. Existen miles de usuarios swing que tendrán de a poco que comenzar a migrar a JavaFX. El problema es que nadie asegura que no vaya a ocrurrir lo que le pasa a Flash y a las miles de otras tecnologías en Internet que tienen un tiempo de vida corto. No se si le pasa a los demás que cuando quieren desarrollar algo en Internet se encuentran con un abanico muy amplio de opciones que no saben por cual decidirse. Si deciden mal y al poco tiempo el proyecto por el cual se decidieron es abandonado comienzan los problemas de falta de actualizaciones y corrección de bugs que ya no se van a dar porque dicho proyecto se abandonó. Considero que Oracle debería darle la oportunidad de crecer a swing que es una tecnología a mi punto de vista sólida, probada y con miles de usuarios en el planeta en lugar de apostar en una nueva tecnología. Ese es mi punto de vista. No se si alguien comparta mi forma de ver las cosas.
Pregunta.
Cuantos de vosotros consideráis que Oracle, IBM, RedHat, SAP y el resto del JCP, deberían trabajar en la evolución de la infraestructura instalada y en ampliar la base de SO's para el JRE?
Esto, independientemente de lo que Oracle allá dicho o este diciendo de estas tecnologías.
Respuesta a la encuesta de efrigerio:
En mi opinión, la mejor solución sería sustituir AWT y 2D por una nueva infraestructura gráfica, y volcarse en la puesta al día de Swing.
Con lo que han aprendido con JavaFX, no creo que les resultase difícil cambiar AWT por Prism. El verdadero "deprecated" es AWT.
Por supuesto que cuanto mayor sea el soporte de Sistemas Operativos, mejor que mejor para Java.
Yo reemplazaría Graphics2D por Java3D con suiche OpenGL in on. Si en su momento cambiar Graphics por Java2D mejoro muchísimo el rendimiento de Swing, esto lo aria aun mas.
También mandaría al diablo a GTK en entornos Unix y lo remplazaría por algo que valla directamente contra las primitivas graficas y utilice aceleramiento por hardware siempre que posible, tal como hiso Opera cuando le dijo adiós a QT (lo que le dio una mejora de rendimiento del 20%).
Asta acá saldrían beneficiados todos los toolkit graficos de la plataforma, Swing, AWT, SWT asta para JavaFX esto es importante.
También se terminaría con el principal escollo para subirse a los SO embebidos vasados en Unix sin X11, (open phone y Android incluidos).
Esto es básico y no rompe compatibilidad alguna.
Nada Tarde. Hacía falta una tecnología que implementara más funcionalidades del lado del cliente... ejecutar javafx en un navegador es casi como ejecutar un programa embebido allí, en el cliente con los permisos para volar; esto, empresarialmente te resuelve muchas cosas (tal vez no tanto para aplicaciones comerciales, pero para requerimientos de aplicaciones "a la medida" no hay color)
De acuerdo con muchos que apuntan que JavaFX no sustituye HTML5, mas bien es para sustituir swing, y la verdad es que va de maravilla, interfaz standalone se hacen en un abrir y cerrar de ojos. El desarrollo para aplicaciones desktop se hace super rapido.
Yo creo que JavaFX es la forma de dejar atrás swing, en JavaFX las aplicaciones son mucho más fáciles de hacer y la interfaz gráfica mejora enormemente. Es cierto que HTML5 maneja mucha de esta funcionalidad, pero como lo ha dicho Mr.Potato, no creo que el objetivo sea competir con HTML5 o sustituirlo, es la manera de permitir a los desarrolladores Java crear aplicaciones con un efecto visual mejorado sin emplear swing.
Tenía una aplicación en Swing. Necesitaba incorporarle manejo de archivos mp3. Bicheando por ahí pensé que la solución era JavaFX. Pues bien, en 10 días he desarrollado las versiones JavaFX de las clases de mi aplicación. Naturalmente las que trabajaban fuera de la UI no hubo que tocarlas. Generalmente el código se reduce a un 30-40% -si no más aún- y el tiempo de desarrollo a un 20%, todo ello aproximadamente. El manejo de concurrencia y animación de usuario son excepcionales.
Mi conclusión: JavaFX 2.x es fantástico. Estoy contando los minutos para que el 25 de marzo próximo veamos el lanzamiento definitivo de JavaFX 8.
Un detalle importante: JavaFX tiene detrás Java, con todo lo que eso supone: todas sus librerías para "computación" (funciones matemáticas, librerías de todo tipo, ...), que HTML5 no tiene.
En resumen, HTML5 es para unos usos (presentaciones visuales que entren por el ojo, pero con poca computación interna) y JavaFX es para crear aplicaciones que entren por el ojo .. y requieran además mucha computación interna (p.ej., presentaciones visuales del funcionamiento de simuladores de modelos matemáticos). Creo que no compiten, como no compite un alicate y una llave inglesa.
Yo creo que esta mal planteado tu articulo, no creo que javaFX de Oracle quiera hacer competencia con HTML5, yo creo que más bien fue creado para un "reemplazo" de swing incorporando complejos controles, multitouch, etc,(aunque swing seguirá siendo una buena opción), aparte hay muchos frameworks de java como el caso de JSF,struts que están especialmente dedicados para la web, otro punto es que estos frameworks trabajan con el clásico lenguaje de java incorporando también librerías que facilitan muchísimas cosas (gran deficiencia de php), lo cual a un desarrollador que siempre ha programado en este lenguaje le sea mas fácil aprender estos frameworks que aprender a programar con php y html5, aunque seria genial que javaFX corriera también en un navegador web.