¿Cómo afectará a JavaFX la falta de soporte para modularidad en Java 8?
Abraham
La semana pasada Mark Reinhold, Chief Architect of the Java Platform de Oracle, anunciaba que no sería posible completar el soporte de modularidad para la plataforma Java (Jigsaw) para la fecha en la que estaba previsto terminar Java 8, por lo que o bien Java 8 se retrasaba un año, o bien el soporte para modularidad se caía de Java 8 y tendríamos que esperar por él hasta Java 9. Esta segunda opción era por la que se inclinaba Mark. Y, aunque no me consta que todavía se haya tomado una decisión de modo oficial, todos los rumores apuntan a que eso será lo que se haga.
En el mejor de los escenarios, va a ver que esperar hasta mediados de 2014 por el soporte de modularidad. En el peor (y más probable), tendremos que esperar hasta mediados de 2015. Y esto tiene un impacto importante en JavaFX.
El poder modularizar el JRE es clave para conseguir una descarga ligera para aquellos usuarios que no tienen el entorno de ejecución de JavaFX instalado en su equipo, así como para conseguir disminuir los tiempos de arranque de las aplicaciones JavaFX. Estos dos puntos han sido tradicionalmente dos de las principales desventajas de los Apple Java/aplicaciones JavaFX frente a Flash.
Me acuerdo de una demo que el propio Mark realizó en la JavaOne hace un par de años en la cual empleando un prototipo del soporte para modularidad en Java habían construido una serie de comandos de consola al estilo de "ls" en Java. Esto a día de hoy no es algo que se pueda hacer de un modo viable porque al añadir al tiempo de ejecución del comando el tiempo de arranque de la máquina virtual, el tiempo total de ejecución es excesivamente alto. En la demo de Mark, gracias al soporte de modularidad, era algo aceptable. Pero parece que vamos a tener que esperar hasta 2015 por esto.
El retraso en el soporte para modularidad significa que probablemente hasta 2015 no tengamos este "arranque rápido" y esas descargas más ligeras para las aplicaciones JavaFX. Desde mi punto de vista, esto es otro clavo en el ataúd de JavaFX. ¿Qué opináis vosotros?
Aprovechamos la ocasión para recordaros que estamos llevando a cabo una encuesta acerca de que se debería de hacer respecto al soporte de modularidad, si incluirlo en Java 8 y retrasar la disponibilidad de Java 8 un año, o incluirlo en Java 9 y esperar por el soporte para modularidad tres años:
Reader Comments (7)
Swing se queda anticuado por tener un thread unico para pintar todo lo visualizable, cuando se usan varios thread en aplicaciones de escritorio puedes tener facilmente problemas y tb se debe de estructurar muy bien la aplicacion para que no se quede congelada la aplicacion, el JavaFX creo q soluciona ese problema, añade animaciones, realmente creo que javafx sirve para aplicaciones de escritorio en donde la modularidad no es tan importante con java web start, aunque estaria francamente bien que cuando se desarrolle una aplicacion de escritorio "parezca" una aplicacion web y se descarge "aceptablemente" rapido, por mi parte prefiero esperar y que se haga bien y no tener que parchear y que se queden cosas "deprecated"
infoeduardo
@infoeduardo
"In designing JavaFX 2.0, we of course needed to address both how the scene graph would behave in the presence of multiple threads, and how developers could effectively do work in background threads and keep the UI responsive. In short, the JavaFX scene graph, like all other mainstream GUI toolkits, is not thread-safe and must be accessed and manipulated from the UI thread (call the FX Application thread). Swing and AWT had the same basic policy (only work with Swing or AWT from the Event Dispatching Thread), as did SWT (only interact with SWT resources and components from the thread that owns them), as do all other major toolkits (JavaScript / HTML included)."
http://fxexperience.com/2011/07/worker-threading-in-javafx-2-0/
jo
@infoeduardo
No pongas cara de susto, que no es tan complicado como parece.
JavaFX dispone de interfaces como Worker, y de clases como Task, que funcionan de una manera similar al SwingWorker de Swing.
Una vez que se tiene presente que las actualizaciones del UI deben hacerse en su propio thread, la concurrencia es tan fácil o difícil como si no hubiese un UI.
Si crees que es dificil usar un GUI toolkit con EDT ... si fuera multihilo estarias mas que perdido: http://weblogs.java.net/blog/kgh/archive/2004/10, http://codeidol.com/java/java-concurrency/GUI-Applications/Why-are-GUIs-Single-threaded/
Lo que si creo que tiene JavaFX es que puede hacer rendering en otros hilos
http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm
Threads
The system runs two or more of the following threads at any given time.
JavaFX application thread: This is the primary thread used by JavaFX application developers. Any “live” scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications.
Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering.
Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread.
De todas maneras, si quieres un GUI multihilo en Java: http://www.inf.uos.de/elmar/projects/java-gtk/ (no lo he usado)
El clavo no solo afecta a JavaFx sino tambien a Java para moviles y en parte, incluso al JDK ...
Hombre, Una vez que conoces bien (muy bien) como funciona Swing, pues diseñas la aplicación acorde con el EDT y todo bien (mas o menos), pero si no has tenido en cuenta el EDT, creas un framework, de un solo thread, luego le añades multihilos para carga de formularios,informes, ... en 2º plano con la barrita de proceso integrada en el framework y un monton de utilidades, una vez orgulloso de lo bien que te ha quedado el código, patrones de diseño por doquier, guauu, pues llega el EDT y te dice que los JFrame, JPanel ... en un solo thread, que si no se te puede quedar colgado, te das cuenta de que tu maravilloso diseño es una mier... que solo unos pocos tipos de form. se adaptan bien y el resto ...
@JB
"De todas maneras, si quieres un GUI multihilo en Java: http://www.inf.uos.de/elmar/projects/java-gtk/ (no lo he usado)"
gracias por la sugerencia, aunque prefiero usar lo estandar y apechugar, que ya me ha pasado varias veces que el componente/programa se queda obsoleto
"A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. "
Yo con esto me conformo, aunque Swing tambien decia que podemos construir (pero no mostrar) un GUI en cualquier thread, mientras que no hagamos llamadas que se refieran o afecten a los "componentes ya realizados".
en fin..