Discussion :

[Christian Olivier]

JavaFX sera disponible en tant que module open source distinct du JDK
Et Java Web Start disparaitra à partir de Java 11

Oracle a annoncé que JavaFX, son framework Java qui repose sur l’API Java SE et permet de concevoir des interfaces graphiques (UI) ou des RIA (Rich Internet Application), sera à l’avenir disponible en tant que module open source distinct du JDK (le kit de développement Java). Cette mesure devrait être effective dès la sortie du JDK 11 qui est prévue pour septembre 2018.

En agissant de la sorte, l'entreprise technologique américaine espère faciliter l’adoption de JavaFX et accorder plus de liberté et de flexibilité aux développeurs qui l’utilisent. Elle a estimé que ce framework avait besoin d’un package de distribution et d’un calendrier de publication qui lui soient propres afin que les contributions apportées pour son développement – que ce soit par Oracle ou par d’autres membres de la communauté OpenJFX – soient mieux encadrées.

Il faut rappeler que dans ses premières versions, JavaFX était déjà fourni indépendamment du JDK et du JRE (l’environnement d’exécution). Mais depuis l’arrivée de Java 7 u6 en 2012, les runtimes de ce framework étaient toujours fournies avec le JDK et le JRE. JavaFX devrait néanmoins continuer d’être pris en charge dans le cadre du JDK 8 jusqu’à 2022 au moins. Il restera inclus dans le JDK 9, qui reste le précurseur de la modularisation décrite principalement dans la JEP 201, et le JDK 10.

Signalons au passage que l’objectif principal du système des modules est de fournir un JDK qui puisse être structuré et de pouvoir charger seulement les modules nécessaires.

« Au cours de la dernière décennie, la technologie JavaFX s’est trouvé une niche au sein de laquelle elle bénéficie du soutien d’une communauté de développeurs passionnés. Mais dans le même temps, l’intérêt pour les outils multiplateformes tels que JavaFX sur le marché a été érodé par la montée en puissance des applications « mobile first » et « web first », a écrit la société dans un livre blanc.

Oracle a annoncé en outre que les Applets continueront d’être pris en charge sur Java SE 8 jusqu’en mars 2019, date à partir de laquelle ils pourront être supprimés à tout moment. À la base, les Applets permettaient, grâce à un plug-in, de bénéficier d’un plus grand nombre de fonctionnalités lorsque les capacités du navigateur étaient limitées, mais les navigateurs Web ont considérablement évolué avec le temps et ces Applets semblent aujourd’hui désuets. Java SE 8, de son côté, devrait continuer à être pris en charge jusqu’en janvier 2019.

Oracle a aussi révélé que Java Web Start ne sera pas inclus dans Java 11 et les versions ultérieures. La société devrait continuer à assurer le support de Java Web Start dans Java 8 jusqu’en mars 2025 et encourage les développeurs à abandonner cette solution.

Source : Java Client Roadmap Update (pdf)

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion, sur la liste de diffusion de l'OpenJFX
Oracle compte livrer Java EE 8 en juillet 2017, un peu plus tôt que prévu et le même mois que le JDK 9

[Askeridos]

"Au cours de la dernière décennie, la technologie JavaFX s’est trouvé une niche au sein de laquelle elle bénéficie du soutien d’une communauté de développeurs passionnés"

Faut dire aussi que c'est plus joli et plus customizable que Swing non ?

[deltree]

Faut voir comment il sera fourni ce module: pour l'instant pour faire du openJDK + openJFX il faut compiler soi-même la partie JFX. La solution la plus simple pour avoir du JavaFX aujourd'hui c'est bien d'utiliser le JDK oracle.

[deltree]

Faut dire aussi que c'est plus joli et plus customizable que Swing non ?

Oui surtout avec le FXML et le CSS séparé du code Java, ça découple mieux les concepts, et le CSS est assez facilement customisable.

Une astuce étant d'aller voir les style par défaut dans le css de javafx (dans le fichier modena.css)

[professeur shadoko]

le problème avec java webstart me semble être que les jars modulaires auront du mal a être compatibles.
mais il y a un mais: déjà que les jars "clickables" ne fonctionnent plus en architecture modulaire , comment faire du déploiement avec système de mise à jour? il faudra trouver une technique de remplacement.

[Hind4Dev]

JavaFx est plus fort que Swing, plus flexible à personnaliser grâce au code CSS et plus jolie. Pour le nouveau module, faut voir par la suite si ça facilite les tâches et aide à mieux gérer les bibliothèques, surtout pour les débutants.

[Jitou]

JavaFX est une API bien construite et infiniment plus simple à utiliser que AWT / Swing mais la mode n'est plus au client monolithique mais bien au Web et leurs pléthores de frameworks Javascript difficiles à maintenir et dont la durée de vie est très incertaine.

[bouye]

Et pour ceux qui n'ont pas lu la roadmap: Oracle chercher aussi des parties tierces pour prendre en charge AWT et Swing....

Je ne vais guère plus que cela commenter pour JavaFX mais ça fait maintenant 4 ans qu'Oracle affame sa division desktop et que tout le monde se fait virer ou se casse, sans parler de l'arret par Oracle de la version ARM ou de l'arret de SceneBuilder. Le fait que les discussions récentes de l'OpenJFX a la fin de l’année dernière et au mois de janvier tournaient autour d'une mise en avant de Johan Vos (Gluon) comme figure de proue pour fédérer une communauté autour l'OpenJFX était bien un signe précurseur qu'Oracle allait complètement s'en désengager.

Kevin Rushford a fait du bon boulot de planification sur le découpage des modules, et la priorisation des bugfixes, Laurent Bourges a fait un super boulot (en volontariat en plus) sur MarlinFX. J’espère juste que Johan Vos et la communauté auront la capacite d'ajouter enfin de nouveaux trucs (nouveaux controles*) et de rendre ouvertes et pluggables certaines parties du code qui n'auraient jamais du rester fermées (ex : le support audio et video histoire qu'on puisse rajouter nous-meme le support de nouveaux formats ou de formats legacy, de même que le langage de shader pour les effets graphiques pour en créer des nouveaux). Bref, comme le port mobile et ARM, comme SceneBuilder, je sens bien que c'est parti pour que Gluon supporte le poids de JavaFX entièrement sur ses épaules (avis perso, pas un fait établi), car bon il faudra bien fournir des binaires et on ne va pas laisser les gens devoir recompiler JavaFX eux-mêmes. Bon courage a eux !

*Vu Que Jonathan Giles est parti chez Microsoft il n'y a plus de lead contrôle d'ailleurs pour le moment.

Concernant JWS par contre lui il sera mort et enterré et Oracle ne compte pas le rendre OpenSource, ce qui laisse a penser que le soucis n'est pas d'ordre technique mais légal (technologie sous license par exemple).

EDIT - d'ailleurs Jonathan Giles vient de poster :

I have received a huge number of emails from people wondering what this means for JavaFX. The answer is – it is now in the hands of the community, with companies like Gluon stepping up to take on the load. You can choose to look at this optimistically (faster releases, easier contributions from community, etc) or cynically (another area that Oracle has abandoned and left the community in charge) – for me, I will write a blog post adding more detail about this as soon as possible.

[bouye]

Et voici la réaction de Johan Vos sur Jaxcenter : JavaFX as a separate module: A look back and a leap forward

[CoderInTheDark]

Ca me pose question.

Est-il raisonnable de se lancer encore dans l'apprentissage de FX ?
Le retour sur investissement est-il garanti ?

Si je reste sur Swing, c'est surtout que je le connais bien.
Et globallement on tend vers le tout client riche
Tant que je peux je garde mes projet perso sur Swing, même si je me prive de certains avantages de Fx, qui ne compenssent pas la réécriture.

[bouye]

Cela dépend de ce que tu veux faire car pour certaines parties (HTML, CSS, media) Swing de base (c'est a dire sans surcouche ou lib tierce) est un peu dépassé depuis longtemps. Pour d'autres trucs plus classiques et moins modernes, Swing marche toujours aussi bien et reste une valeur sure. Cependant, Swing n'est pas a l'abri non plus puisque la roadmap est explicite sur le fait qu'Oracle cherche des parties tierces pour le maintenir (et en l’absence de ces éventuels repreneurs, il reste a l’état de zombie comme actuellement : aucune nouveauté a l'horizon).

La réaction de Jonathan Gilles, ex-lead des contrôles JavaFX pour Oracle, actuellement évangéliste Java sur Azure chez Microsoft : One guy's perspective on JavaFX

[Christian Olivier]

JavaFX 11 est enfin disponible en tant que module open source distinct du JDK
Tour d’horizon des améliorations et des nouveautés

Lors de l’annonce des fonctionnalités du Java Development Kit (JDK) (JDK) 11, Oracle a indiqué qu’il procèderait, à partir de cette version, au retrait des modules non essentiels du JDK et à la mise en place de modules indépendants bénéficiant d’un meilleur suivi.

Cette mesure devait permettre aux modules cibles d’être fournis indépendamment du JDK afin qu’ils puissent être développés à leur rythme, sans être impactés par la nécessité de devoir sortir une nouvelle version tous les 6 mois parallèlement à la sortie d’un nouveau JDK.

Les runtimes de JavaFX ont longtemps été distribuées sous forme de bibliothèque tierce séparée du JDK jusqu’à son inclusion dans le JDK 7 lors de la publication de JavaFX 2.2. Oracle avait annoncé que JavaFX, son framework Java qui repose sur l’API Java SE (Standard Edition) et permet de concevoir des interfaces graphiques (UI) ou des RIA (Rich Internet Application), sera à l’avenir disponible en tant que module open source distinct du JDK (le kit de développement Java).

JavaFX 11 est enfin disponible et se positionne, par la même occasion, comme la première version autonome de JavaFX depuis la publication de JavaFX 2.2 et l’intégration de ce dernier dans le JDK 7. Il prend en charge MathML et inclus la fonctionnalité FX Robot API pour simuler les interactions de l’utilisateur.

Sur cette version, les modules JavaFX autonomes n’ont plus la permission par défaut et le support est offert pour FX Swing interop en utilisant une API publique. MarlinFX, le portage du moteur de rendu Marlin qui calcule la proportion des pixels couverts par les formes Shape en estimant le nombre de sous-pixels couverts, a été mis à niveau vers la version 0.9 avec la promesse de performances revues à la hausse.

On peut également signaler la mise à jour de GTX (Gimp Toolkit) par défaut vers la version 3, l’ajout de couleurs standard à la palette de couleurs ColorPicker et l’amélioration de la classe Bounds. Cette version corrige en outre certains bogues, notamment une fuite de mémoire dans VirtualFlow lorsque le lecteur d’écran était activé et un problème qui était en rapport avec la table de redimensionnement automatique.

JavaFX 11 plante avec OpenJDK 11 sur les PC Linux tournant sous Ubuntu 18.04 avec Wayland activé. L’utilisation du serveur Xorg est recommandée pour contourner ce problème. Le JDK n’incluant plus JavaFX, les développeurs doivent explicitement inclure les modules JavaFX dans les applications.

Source : JAVA

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Interview de Laurent Bourgès, contributeur sur l'OpenJDK 9 la prochaine version de Java
Quel environnement de développement intégré Java utilisez-vous en 2018 ? Et pourquoi ?
FAQ JavaFX
JavaFX sera disponible en tant que module open source distinct du JDK et Java Web Start disparaitra à partir de Java 11

[gstratege]

Moi je ne comprend plus rien dans Java.
Un coup Java va devenir payant par Oracle.
Un coup Java va être transféré à Eclipse : dans ce cas comment il va être payant ?
JavaFX de cet article sera-t il payant ?

N'hésitez pas à répondre si vous comprenez mieux ce qui se passe dans la monde Java.

[lbobinet]

Si je me rappelle bien du feuilleton:

Java reste gratuit, mais les versions obsolètes sont en support payant
Java EE a été lâché par Oracle et cédé à la fondation Eclipse
Java FX a été créé indépendamment du JDK (kit standard de dev), puis y a été intégré, et maintenant s'en retrouve séparé à nouveau

[Mickael_Istria]

Un coup Java va devenir payant par Oracle.

Pour etre plus precis: L'implementation OracleJDK du language Java va devenir payant.
Java, le language, la specification, reste gratuit.
Il y a d'autres implems qui restent gratuites telle qu' AdoptOpenJDK, et il y a eu des implem payantes de Java avant ca. Au final, ca ne change rien au fondamentaux, c'est juste l'offre d'Oracle qui evolue, mais le language reste gere comme il l'etait avant.

Un coup Java va être transféré à Eclipse

Non, il n'a (pour l'instant) jamais ete question que Java soit transfere a la communaute/fondation Eclipse.
C'est Java EE qui a ete transfere. C''est pas pareil Java (le language) et Java EE (les APIs "enterprise").

JavaFX de cet article sera-t il payant ?

Le code de JavaFX sera open-source et gratuit.
Apres, Oracle a tout a fait le droit de prendre ce code, et de le mettre dans leur offre payante; AdoptOpenJDK a tout a fait le droit de prendre ce code, et de le mettre dans leur offre gratuite... Toi, tu as le droit de prendre ce code, et de te faire ton application avec si tu preferes ca a ce que proposent les fournisseur de JVM.

[darklinux]

Bon , pas de quoi fouetté un geek . Non il n ' y a que le support de la JVM d ' Oracle qui est payante , mais elle n 'est pas la référence . C est l ' Open JDK .

[ScientificWare]

Merci Christian d'avoir évoqué MathML dans les fonctionnalités de JavaFX/OpenJFX!

Effectivement les personnes qui savent que JavaFX supporte nativement MathML sont peu nombreuses.
Cette possibilité n'a jamais été documentée ? ? ?
Alors voici une copie d'écran pour donner un exemple, ce sera plus parlant.



Travaillant sur le support de l'écriture et de l'édition mathématique depuis 2007 dans Java/Swing, cette fonctionnalité m'intéressait au plus haut point !

Mais ce n'est qu'en 2015 et un peu par hasard au détour d'une réponse à un post, que j'ai découvert que JavaFX supportait aussi MathML.
Malheureusement, après un rapide essai, il s'est avéré que cette fonctionnalité était cassée depuis 2011.

Pendant 2 ans, j'ai attendu en guettant d'éventuels progrès.
Puis en 2017 et 2018, je me suis lancé avec mon anglais approximatif.
D'abord sur la liste de l'OpenJDK/JFX puis sur le nouveau dépôt GitHub de JavaFX/OpenJFX.
La première réponse a été : Il existe bien un rapport de bug JDK-8147476 mais sa correction n'est pas programmée, alors si vous être pressé vous pouvez le faire vous-même.

Whaou, quel défi !
Quelques semaines de travail détaillées là JavaFX and MathML.
Pour aboutir finalement comme "un grand" à un correctif JDK-8147476 : Rendering issues with MathML token elements. #117 juste pour la sortie de JavaFX11.

J'avais hésité un moment avant d'oser me lancer, un de mes correctifs concernant le JDK avait mis 5 ans avant d'être accepté.
Cette fois-ci avec la nouvelle politique pour JavaFX et une petite mais précieuse aide de l'équipe de développement tout cela a été fait en 3 mois, test compris.

Depuis je parcours les forums pour le dire et surtout le montrer car la pérennité de ce support dépend du nombre des utilisateurs. Il ne manquait plus que mon site préféré, voilà c'est chose faite.

Je dois aussi remercier Frédéric Wang de la Société Igalia pour avoir répondu à mes questions sur son travail sur MathML.
J'espère qu'il parviendra à nous offrir également le support de MathML au sein de Chromium après avoir œuvré au cœur de WebKit.

Pour les plus septiques, j'ai mis un petit bout de code ici : Keep an answer which could be deleted in StackOverFlow.
Pour l'essayer, le plus simple est d'utiliser la version de Java 8 192 ea ou celle qui doit être publiée à partir du 25 septembre (c'est la dernière version du JDK qui contiendra JavaFX ).
Attention, ce bug ne devrait pas être corrigé dans les versions 9 et 10, sauf souscription à un support personnalisé auprès d'Oracle.
Avec JavaFX 11 c'est un peu plus compliqué.

On obtient ceci :


Justement, l'avenir de JavaFX et du SDK Java est très bien expliqué ici Java release chains - Splitting features from security

Alors n'hésitez pas à mettre les mains dans le cambouis !