¡JavaFX 2.0 es multiplataforma!
AbrahamLa verdad es que el título de la noticia es un poco irónico. Pero es el mismo título que ha empleado Oracle. Aproximadamente seis meses después de liberar la primera versión estable de la plataforma, por fin Oracle anuncia una versión de Java FX (la 2.1) con soporte para Linux. Eso sí, se trata de una versión "Developer Preview". Y según el roadmap de la compañía no habrá un soporte para Linux estable ("GA") hasta la versión 2.2 que está prevista para después de este verano (probablemente se anuncie en la JavaOne).
Es decir, habrá pasado un año desde que se anunció la primera versión estable de JavaFX hasta que se anuncie la primera versión estable que soporta Linux. Primero, no parece muy serio para que la gente confíe en esta plataforma. Segundo, hace que uno tenga duda sobre el compromiso que Oracle va a tener con el carácter multiplataforma de Java, al menos respecto a lo que aplicaciones de escritorio/RIA se refiere.
Como ya hemos comentado un montón de veces en este portal, en general la comunidad de desarrolladores Java no ve claro que la tecnología JavaFX vaya a despegar, y más por el chasco de JavaFX 1.0. Los retrasos se Oracle en convertir a esta tecnología en auténticamente multiplataforma (uno de los principios más básicos de Java) no le están ayudando en absoluto a fomentar su adopción.
En cualquier caso, los interesados en JavaFX y usuarios de libros a la vez, al menos ahora podrán comenzar a probar la tecnología.
Reader Comments (29)
Pues a mi me parece algo normal. El cambio de la versión 1.X fue bastante grande, así que es normal que no quieran dar soporte a todas las plataformas desde el inicio.
Desde el mismo día en que JavaFX pasó a ser un proyecto Open Source, se ha observado una enorme actividad en el desarrollo.
Una de las consecuencias es que la versión Developer Preview para Linux, que estaba prevista para este verano, se ha adelantado casi seis meses.
Dada la enorme dependencia de JavaFX de código nativo, me parece bastante natural que haya retrasos en la implementación para diversas plataformas.
La idea de fondo, en la que ya se está trabajando con intensidad, es que JavaFX se integre plenamente en el OpenJDK, de tal forma que la dependencia respecto de código nativo se resuelva directamente por el HotSpot. No está previsto hasta la versión JavaSE 1.8 aunque puede haber sorpresas, y tal vez futuras versiones de HotSpot para JavaSE 1.7 incluyan soporte directo para JavaFX.
Si las principales dudas para la adopción de JavaFX se refieren al soporte de las plataformas habituales, el estado del desarrollo actual, y las previsiones a corto plazo, invita a despejarlas.
que diferencia hay entre una app fx y una app swing que se actualiza sola contra un server?
Cual es la diferencia entre java fx y una aplicacion swing que se actualiza sola como jdownloader ?
Swing y JavaFX son tecnologías diferentes con las que construir un GUI.
El modo de actualización de una aplicación de escritorio, no tiene relación con el GUI que se utilice.
Las principales dudas sobre JavaFX, desde mi punto de vista, tienen que ver con que ¿qué coño quiere hacer Oracle con eso? Oracle es una compañía muy orientada a la monetización, no como Sun. Si están invirtiendo es que esperan sacarle dinero. Hace un año todo el mundo pensaba que la idea de JavaFX era competir con Flex, la tecnología que domina el mercado. Ahora que esa tecnología ha sido abandonada por su dueño, estando en una posición completamente dominante en el mercado ¿qué cojones hace Oracle apostando por una tecnología similar? -Como la va a monetizar?
Yo creo que puede terminar como JavaFX 1.0. Y lo que no me parece nada serio respecto a JavaFX y su carácter multiplataforma es que Oracle nos haya dicho que swing está "deprecated" y el futuro va por JavaFX, pero JavaFX no es multiplataforma…
JavaFX es una tecnología destinada a reemplazar a Swing, a medio plazo.
Que lo consiga o no, aun está por ver; pero esa es la intención.
Conviene caer en la cuenta de que, por el momento, es una tecnología "en desarrollo":
no está terminada, en el sentido de poder usarse en producción.
Respecto a su soporte multiplataforma, es curioso que hace tan solo seis meses, la crítica era que solo soportaba Windows; mientras que ahora, que ya tiene, aunque en pruebas, soporte para Mac OS X y Linux, la crítica sobre la multiplataforma continúa como si no se hubiese hecho nada al respecto.
Swing, lo mismo que javaFX, no son tecnologías para desarrollo "exclusivo" para la Web.
Creo que todavía se tiene la manía de pensar solamente en términos "web", y obviar que el desarrollo empresarial e industrial, en su mayoría interno y propietario, se hace para aplicaciones de Escritorio.
Y es en esos sectores donde están los principales clientes, no solo de Oracle, sino de las demás corporaciones que contribuyen, tanto al desarrollo de Java como de JavaFX.
Para los que no lo habéis echo, echadle un ojo (mejor un oído ;) ) al Podcast - 128 - El futuro de las aplicaciones RIA.
Si bien quedo un poco desdibujado, en él hablamos de JavaFX y Swing.
Mi postura es que independientemente de que en JavaFX halla cosas que técnicamente no comparta (WebKit por ejemplo). lo peor que se puede haser en java con las GUI es un borrón y cuenta nueva devido a las toneladas de código que ya existe.
Otra historia es decir que Solaris, Linux, Windows y Mac OS X, sin Android, QNX, iPhone OS o Windows Metro, Hoy por hoy, es multiplataforma.
O que un navegador con HTML5 tenga mas funcionalidad que una GUI en java.
Un saludo.
Si por borrón se entiende que Swing se va a eliminar del OpenJDK, no hay de qué preocuparse, porque no se va a "borrar".
El término "deprecated" aplicado a Swing es una invención mediática.
Swing no está deprecated, ni lo estará en muchos años.
mi planteo va en relacion a que en las empresas se empeñan en hacer aplicaciones web con GWT, Flex o Richfaces cuando en realidad lo que necesitan es una app de escritorio con un framework super robusto como swing que se actualice solo nada mas.
@dario
Ya se está haciendo, por ejemplo usando NetBeans Platform.
No hay nada, por ahora, que impida integrar componentes JavaFX en aplicaciones Swing, y por consiguiente usarlos en la Platform, como el resto de Swing.
Pienso que el fracaso del javafx1.0 radica en que se estaba inventando innecesariamente un lenguaje, cuando en realidad lo que se requiere es este javafx2.0 que sea un swing mas avanzado. Concuerdo con la preocupación acerca del como Oracle monetizara javafx, Sun era capaz de agregar la barra de google o buscar publicidad, pero Oracle siempre quiere hacerlo todo en grande. Pero no creo que javafx2.0 fracase, puede que no sea una tecnologia super relevante o super twitteada, seguro tendra un lugar en el desktop.
Reiteradamente, prometo que no usaré Java hasta que aparezca la sentencia GOTO <label>.
Yo le doy larga vida a Swing, por varias razones.
Y si me piden consejo sobre que tecnología utilizar para escritorio, JavaFX o Swing, yo recomiendo Swing. Y si personalmente tengo que hacer escritorio, yo elijo Swing.
JavaFX primero tiene que demostrar su viabilidad, muy en entredicho por los hechos pasados y presentes (y el incierto futuro...) y por la confusa política de promoción de Oracle al respecto. Después JavaFX está muy verde, seguramente tiene gran potencial pero en cuanto a madurez obviamente Swing barre literalmente a JavaFX. Ahora bien, para experimentar un poco, para que jueguen los estudiantes a hacer efectos especiales, para incluso juguetear con alguna aplicación móvil etc... bueno, por jugar que cada cual emplee su tiempo como quiera, pero ahora bien para los temas serios y las cosas de comer está Swing, que es la que sabemos que a día de hoy te va a proporcionar el soporte necesario.
Yo también creo que es un error que estemos tan volcados en web, como si fuera la única manera válida posible para cualquier tipo de requisito.
Y cuando salgo a la calle todavía veo montones de aplicaciones corporativas no solamente a 16 colores sino hasta monocromáticas. De hecho cuando voy al aeropuerto veo que Amadeus (creo que es Amadeus lo que digo) está en blanco y azul, o sea, para que veamos a la hora de la verdad por donde se pasan las decisiones importantes los gradientes, los efectos de sombra, las transiciones tridimensionales y los efectos especiales.
Swing lleva camino de convertirse en una de esas legendarias tecnologías carne de perro que durarán y perdurarán contra todo tipo de modas y novedades, y que siempre será elegida a la hora de tomar decisiones importantes. Es demasiado sólida como para "deprecarla", y a la vez sencilla y potente. Y es para aplicaciones de escritorio profesionales, no para hacer tonterías con el móvil.
Swing no se va a retirar del JDK, al igual que muchas otras cosas (algunas de las cuales sería mejor que no estuviesen) siguen estando en él por motivos de compatibilidad hacia atrás. Pero el discurso de Oracle es que Swing es el pasado. Sus evangelistas dicen literalmente que "Oracle ya no le va a dar mucho amor a swing", que no se va a desarrollar nueva funcionalidad, que sólo se va hacer mantenimiento. Que el futuro es JavaFX. Claro que podrían estar diciendo esto porque se lo crean de verdad, o simplemente como estrategia para empujar a los desarrolladores hacia JavaFX. En cualquier caso, por la parte que me toca, yo sigo con swing. No voy a invertir tiempo en JavaFX hasta que esté convencido de que no va a terminar como la versión 1.0....
Los "predicadores", sean de Oracle o no, pueden decir lo que quieran, pero la realidad es que en JavaSE 1.7 se han introducido mejoras en Swing, como el uso de genéricos en JList y JComboBox, amén de múltiples mejoras en las implementaciones; y en el desarrollo actual de JavaSE 1.8 ídem de lo mismo.
El desarrollo de Swing no está paralizado en modo alguno, aunque tampoco es que avance de una manera radical, como siempre ha sucedido. Existe un temor justificado a romper la compatibilidad descendente, por lo que "tocar" el API público es un tabú muy conocido.
He tenido, y tengo todavía, la oportunidad de contribuir al desarrollo de JavaFX, y sin embargo estoy "a la expectativa", siguiendo muy de cerca las discusiones y los changesets, mientras sigo usando Swing como siempre.
No creo que las perspectivas y potencialidades de JavaFX vayan a, ni deban, paralizar el desarrollo en Swing.
De hecho se ha avanzado mucho terreno en la interoperabilidad entre JavaFX y Swing, en estos últimos meses. Si hay una intención de fondo en ello, es que coexistan sin dificultades, durante todo el tiempo necesario.
No estoy en absoluto de acuerdo con esa idea de que JavaFX sea "un juguete", para "hacer tonterías en el móvil". Es una plataforma GUI completa, o deberá serlo en cuanto se complete su desarrollo. Es evidente que no se pueden comparar, en términos de madurez, JavaFX y Swing.
Pero Swing adolece de dificultades estructurales, que no se pueden corregir sin romper todo el código existente: su dependencia de AWT y Java2D.
Visualizar datos, animados o en tiempo real, en 2D o 3D con Swing es un dolor.
Redibujar una imagen estática, que no sea un thumbnail, mientras se redimensiona el contenedor, es otro dolor (de ojos).
El soporte multimedia en Swing es prácticamente inexistente. Y en la implementación de JavaSE otro dolor. Es inconcebible que a estas alturas Java no tenga soporte para CDAudio, por ejemplo. Mejor no hablemos de vídeo.
JavaFX plantea soluciones a todas esas cuestiones. Ya veremos cómo se resuelven; pero no hay duda de que en el desarrollo moderno no se puede seguir con tecnologías atrasadas. Y desgraciadamente, el tándem AWT, Java2D, y Swing lo son.
choces, lo de la "juguetería" es una forma de hablar, no hay que tomarlo con tanta literalidad.
Pero veo de todas formas que estamos de acuerdo: que JavaFX está todavía verde y tiene mucho que demostrar y madurar y mostrar que es viable. Mientras tanto en las cosas serias nos vamos a lo seguro, que es Swing, a pesar de las limitaciones que tenga, pero a día de hoy nadie en su sano juicio va a empezar un desarrollo serio de escritorio en JavaFX. Yo creo que esa es la realidad. Por eso hablaba de "jugar", porque a día de hoy de poco mas sirve, no por capacidad sino por lo que acabamos de decir.
También creo que estamos de acuerdo en que cada tecnología tiene su especialidad en el tipo de aplicaciones. Yo creo que está bien decir que JavaFX va a ser para " 'jugar' con los móviles", queriendo esto decir que va a ser para aplicaciones altamente visuales. Está claro que con Swing también se pueden hacer muchas cosas pero teniendo en cuenta que Swing es para hacer "aburridas" aplicaciones de escritorio, mostrar tablas y rellenar formularios, para eso es Swing, y de vez en cuando se saca una gráfica o alguna otra cosa, y para lo demás que se encargue JavaFX de primeras y si con el tiempo demuestra que también sirve para sustituir a Swing en las aburridas aplicaciones de gestión empresarial pues entonces la gente también utilizará JavaFX para eso. Yo opino de todas formas que para eso todavía quedan laaaaaaaaaaaargos años... si es que llega... que está por ver...
Insisto en la buena reputación que se ha ganado Swing como "carne de perro" para "aburridas" aplicaciones de gestión empresarial de escritorio, y va a ser difícil competir con eso incluso a largo plazo.
Pero en fin, todo está en el aire, ya veremos, pero por lo que veo desde el asunto Sun y Java empiezo a pensar que los de Oracle no son tan espabilados, tanto monetizar y tanto monetizar y no hacen mas que meter la pata y haciendo(se) daño en muchos aspectos desde entonces, siendo JavaFX-Swing uno de estos aspectos. Yo cuando veo la política mediática de esta gente al respecto me echo las manos a la cabeza, de tan poco cuidado que tienen (y no se si tienen las ideas claras...) se lo acabarán cargando todo o mejor dicho haciendo daño a Swing y encima a lo mejor vuelve a fracasar JavaFX. Vamos, que lo están haciendo fatal de la manera que lo están publicitando.
Saludos.
@Antonio
Sinceramente, no veo aquí:
http://netbeans.org/features/platform/showcase.html
ni aquí:
http://netbeans.dzone.com/eu-ballistic-crime-and-netbeans
esas aburridas aplicaciones de escritorio que mencionas :)
Hombre choces, el caso es que no estemos de acuerdo :D
Yo no quiero decir que no se puedan hacer grandes cosas con Swing, lo que digo es que donde mejor se desempeña Swing (quiero decir desde el punto de vista funcional y "consultorial") es en aplicaciones de gestión empresarial en escritorio, es decir: tablas y formularios.
Opino que, sobre todo en este aspecto, se puede hacer mucho mas en cuanto a armazones de desarrollo. Es cierto que está Java WebStart para el despliegue, pero faltan armazones de infraestructura de desarrollo. Si algunas cosas de menor entidad a lo que digo se intentaron, como Beans Binding y Swing Application Framework, ambos abandonados, imaginémonos como se iban a dedicar a plantearse proyectos mas ambiciosos.
Yo creo que es definitivamente una desgracia (también para el cliente final, normalmente "deficientemente" aconsejado porque lo que quieren es venderle la moto, y cuanto mas cara mejor... ) que estemos tan pegados al modelo web, como si ahí se acabara el mundo, y eso es falso, potencial hay para el escritorio incluso para trabajar en múltiples capas, solo que no se ha dedicado ni un minuto de tiempo ni un duro de dinero en profundizar en este aspecto.
Saludos.
Hombre Antonio, ¿Te parece que NetBeans Platform no es un armazón de desarrollo con suficiente capacidad?.
Precisamente Swing Application Framework fue un intento, afortunado en su día, que fracasó en integrarse en el OpenJDK porque no ofrecía un marco de desarrollo moderno y capaz.
Por esa razón es ahora un plugin opcional en NetBeans, lo mismo que las Swing Layout Extensions (deprecated de hecho).
No cabe duda de que las aplicaciones administrativas son una parte importantísima en el desarrollo empresarial. Pero estarás de acuerdo conmigo en que no son las únicas.
Y aún en su caso, crear diagramas y gráficos empresariales en Swing es otro dolor. Solo conozco, y uso, una librería externa, jFreeChart, que es pesadísima de manejar.
Comparada con ella, JavaFX Chart es otro universo.
Ves, si es que te gusta llevarme la contraria, jeje.
Yo no me estaba refiriendo a ese tipo de plataformas que están centradas SOLO en la vista, me refiero a una plataforma de desarrollo multicapa con escritorio en la vista, igual que en web, pero en escritorio, y no es que no se pueda, que se puede, y no es que sea mas difícil, que no lo creo, es que sencillamente no se ha querido hacer. No se si se ve la diferencia en lo que hablo.
En Java hay una infinidad de armazones web (multicapa) y que yo sepa ninguno en escritorio. Yo estaba construyendo una plataforma bastante ambiciosa en ese aspecto pero lo tuve que interrumpir, y la idea era muy buena, solo que hace falta muchas horas de investigación, diseño y programación, pero el proyecto es viable solo que en este momento yo solo no puedo.
Y no, yo nunca he dicho que sean las aplicaciones empresariales de gestión las únicas, lo que digo es que en la práctica y a la hora de hacer proyectos que puedan implicar desembolso es ahí donde Swing puede dar lo mejor. Si yo tengo que hacer una aplicación muy visual posiblemente no elegiría Swing, es decir no elegiría Java, si es que se me va a complicar mucho el asunto, pero si tengo que hacer una aplicación empresarial entonces no me lo pienso, utilizo Java-Swing.
Lo bueno es que ahora JavaFX se puede integrar en Swing, así que excelente, pongo toda la infraestructura Swing y cuando tenga que hacer un diagramito, un grafiquito, un dibujito, una fotito o cualquier otra chorradita pongo el JFX Chart o lo que sea dentro de un JPanel (es un decir, no conozco mucho JFX ni tampoco como se integra en Swing) y aquí paz y después gloria. Esto ya suena bastante mas interesante.
Cuando dices que NetBeans Platform solo está centrada en la vista... la vista me falla :D
¿Qué capas le echas en falta?
Vaya, a lo mejor estoy con una idea equivocada, pero... ¿con la plataforma NB puedo hacer una aplicación en tres capas? O mínimo quizás cuente con infraestructura para facilitar el desarrollo cliente-servidor, es decir hacer lógica que habla con la BBDD. No lo se, ya te digo, pero la idea que tengo no es esa, pero quizás estoy equivocado, yo entiendo que la p. NB sirve para componer paneles, vistas, hacer acoplamiento, levantar la aplicación, mantener hilos y muchas otras facilidades similares, pero no la infraestructura necesaria para hacer multicapa. Con multicapa me refiero grosso modo a lo mismo que hace el web: si se usa http entonces el modelo solicitud-respuesta, se pide un servicio que se procesa en el servidor (normalmente preguntando a la BBDD) y que manda una respuesta y el cliente sabrá como desplegar esa respuesta, bajándose la correspondiente vista del servidor si no dispone de la misma, y en este caso con vista hablamos de pantallas Swing, es decir JPanel básicamente. No necesariamente tiene que ser http, se puede hacer de otras maneras.
Quizás lo mejor sea que le eches un ojo detallado:
http://netbeans.org/features/platform/features.html
Tendré que dedicar un tiempo a mirar bien la Platf.NB pero por lo que he visto creo que no estamos hablando exactamente de lo mismo aunque es bastante parecido.
Si la plat. NB es capaz de comportarse como un navegador, descubriendo y bajando automáticamente de un servidor módulos en tiempo de ejecución bajo demanda, detectando en caliente que nuevas versiones de esos módulos están disponibles para las siguientes consultas y por tanto volviendo a bajar la nueva versión del módulo y recargando las clases en tiempo de ejecución para la próxima consulta, entonces mas o menos sí estaríamos hablando de lo mismo.
En el caso de NB creo que los módulos serían jars con lógica de negocio y presentación que por ejemplo podrían hacer consultas al modo cliente/servidor a una BBDD, o llamar a servicios web, o EJBs o cualquier otro tipo de operación.
Pero le echaré un vistazo porque es interesante. Pero también parece pesado porque utiliza OSGI o el sistema modular propio de NB, que supongo que también debe de ser pesado (no se cual de ellos utiliza el IDE). Espero que Jigaw simplifique la modularidad y si sirve para proporcionar la funcionalidad que he dicho antes pues mejor que mejor.
La solución que yo estaba preparando tiene las características que he dicho antes, a saber: descarga automática de componentes bajo demanda en caliente desde la parte servidor de la plataforma y actualización por recarga de clases en caliente en la parte cliente de la plataforma, pero con el requisito extra de ser extremadamente ligero y extremadamente eficiente, porque la plataforma NetBeans es extremadamente pesada, no hay mas que ver el tiempo que tarda en arrancar (cargando los módulos...) y la tajada de memoria que ocupa. Si me puedes confirmar que PNB cumple esto me das una alegría.
Y veo que PNB tiene un sistema de dependencias modulares que es una de las opciones que barajaba para implementar mi solución, quizás me sirva de inspiración.
Gracias por el enlace y saludos, creo que me va a servir y quizás me ponga a aprender PNB.
NetBeans IDE utiliza NB Platform, pero son cosas diferentes.
NetBeans IDE es una aplicación de escritorio desarrollada con NB Platform. Por tanto los recursos que utiliza el IDE no se deben confundir con un estándar de la Platform.
De todos modos, NB Platform está pensada para crear aplicaciones de escritorio, no clientes de un servidor de aplicaciones. Aunque en la práctica, las diferencias pueden ser de detalle.
Como detalle anecdótico: en una aplicación de NB Platform se puede incrustar un Glassfish completo, por lo que...
... pero no es lo mismo...
A mí me despierta mucho interés esta tecnología, y diré la razón: ESTOY HARTO DE SÓLO UTILIZAR LA WEB Y EL NOMBRE MOLA MUCHO (JAVA FX SUENA A EFECTOS ESPECIALES).
Es así de absurda y sencilla mi opinión.
@Antonio Sanchez,
Por lo que he investigado NetBeans hace todo lo que necesitas, te ahorra muchísimo código a la hora de hacer aplicaciones Desktop con Swing.
Con NetBeans platform puedes hacer una app con la cantidad de capas que quieras y bien modular.
¿Que Necesitas hacer con swing que crees que no puedas hacer con NetBeans Platform?
Saludos,