Quel avenir pour JavaFX ? Oracle semble se désengager de la boîte à outils,

Donner votre avis

Le 16 novembre dernier, Dirk Lemmermann postait sur son blog un billet dans lequel il discutait des raisons pour lesquelles, à son avis, l'utilisation de JavaFX peut être préférable à celle de HTML 5. Dirk venait en effet de présenter à la JavaOne plusieurs cas d'utilisation de JavaFX pour des outils de production par de grosses compagnies (VolksWagen, Emirates Airlines, etc.)

Quelques jours plus tard, le 19 novembre, Shai Almog, ancien employé d'Oracle ayant travaillé sur LWUIT, la boite à outils graphiques pour JavaME publiée par Sun Microsystems/Oracle, et un des fondateurs de Codename One, une compagnie spécialisée dans la création d'un toolkit Java multiplateforme mobile basé sur LWUIT, lui répondait dans son propre blog de manière plutôt brusque en exposant, qu'à son avis, Oracle ferait mieux de procéder à un grand nettoyage par le vide et d’abandonner la technologie afin de repartir totalement de zéro. Il en profitait également pour attaquer violemment Gluon, la compagnie récemment décorée à la JavaOne, qui s'occupe de porter JavaFX sur les plateformes mobiles.

Des réactions n'ont pas tardé à se faire entendre des quatre coins de l'écosystème JavaFX, entrainant une discussion sur la liste de diffusion de l'OpenJFX dans laquelle les développeurs exposaient leurs griefs et demandaient à Oracle de se positionner une bonne fois pour toutes quant à son support et son investissement sur le long terme concernant JavaFX.

• Les gros clients potentiels pensent que les atermoiements et les repositionnements (ou même manque de positionnement) d'Oracle envoient de mauvais messages/des messages contradictoires. Certains se posent donc des questions sur la pertinente du choix de cette technologie et commencent à demander des éclaircissements à leurs contractants/exécutants.
• Un conférencier indique qu'il voit ses propositions de présentations refusées ici et là au motif que la technologie n'est pas porteuse ou est déjà morte (opinion qui provient ici aussi de rumeurs et on-dit. Il ne me semble pas que la Devoxx ou que les principales conventions européennes se soient réellement intéressées à JavaFX ces dernières années. La technologie est principalement présente lors des conventions Oracle (voir plus haut Oracle & produits JavaFX).
• La communauté open source semble réticente à se lier aux formalités légales du CLA d'Oracle pour les devs de l'OpenJDK (et je les comprends tant la procédure est lourde).
• Paradoxalement, le passage du Jira vers le bug system de l'OpenJDK rend tout le processus de dialogue avec les devs bien moins ouvert que par le passé (idem pour leur disparition d'OTN ou le fait que la mailing list soit moins active que par le passé). Par exemple, il est désormais impossible d’avoir une discussion ouverte similaire à celle qu’on avait eue sur le JIRA à propos de l’API Dialog ajoutée dans 8_40. Il n'est plus possible de commenter ou de voter sur des tickets pour les non-signataires.
• Certains (CodenameOne) appellent à l'abandon de la technologie sans clairement indiquer ce qui pourrait la remplacer côté client desktop (à part leur propre technologie propriétaire). À noter que le fondateur de CodenameOne a accusé Gluon de vendre la poudre de perlimpinpin (version soft).
• Le rachat récent de RoboVM par Xamarin et le passage du produit en licence commerciale fermée oblige désormais Gluon à aller voir du côté du projet OpenJDK de port du JDK sur plateformes mobiles. Or, on ne sait pas trop ce qu'il en est de l’état d'avancement de ce projet qui a été récemment annoncé (et qui concerne simplement au départ un passage en licence open source d'outils développés par Oracle en interne). De leur côté, les clients de Gluon vont désormais avoir le choix entre devoir payer une licence commerciale de RoboVM, conserver la dernière version open source de RoboVM ou se tourner vers cet hypothétique port mobile de l'OpenJDK.
• Cela oblige également Gluon à accélérer le développement d'une API « socle commun » permettant d’accéder aux capacités natives du téléphone/de la tablette depuis le code Java (précédemment, il suffisait d'appeler directement l'API Android ou d'invoquer Cocoa via RoboVM).
• Du coup, ça fait quand même pas mal de choses à gérer pour une startup qui a moins d'un an (deux si on compte son prédécesseur Lodgon) et qui doit gérer à elle toute seule les principaux outils mobiles (ports et API additionnelles) et desktop (SceneBuilder), mais qui veut aussi continuer à rester open source (mais avec des options commerciales). Pas sûr qu'une grosse entreprise y voit une solution pérenne et désir investir donc.

En tout cas la tempête dans le verre d'eau a commencé à prendre de l’ampleur, engendrant cette discussion sur la mailing list de l'OpenJFX : http://mail.openjdk.java.net/piperma...er/018275.html de la part de gens qui cherchent à obtenir un positionnement clair d'Oracle. Cette discussion indique que plusieurs clients potentiels ou compagnies sont du coup sur la défensive et sont en train de réviser leur jugement suite au billet de blog de Shay et surtout suite au manque de réaction d'Oracle (ben c'est un corporate... je doute qu'il réagisse de toute manière).

On a eu aussi quelques interrogations similaires de notre côté : http://www.developpez.net/forums/d15...x/javafx-sure/ avec un participant qui m'a également demandé mon avis directement par message privé.

Mon avis reste le même : je n'en sais rien, Oracle ne fait qu'envoyer des signaux contradictoires, se focalisant sur le cloud et la modularisation du JDK 9.

Le Java côté client desktop est exactement dans le même état précaire qu'en 2005 quand Sun annonçait un renouveau de Swing. Renouveau qui s'est soldé en 2006-2007 par le départ de chez Sun (qui entamait sa faillite) de tous les intervenants des équipes Swing et 2D connus de l’époque (Scott Violet, Chett Haase ainsi que notre propre Romain Guy - Gfx qui fréquentait le forum à l’époque – et qui ont fini chez Google sur Android). Ce qui me désole aussi c'est les gens qui ne se rendent pas compte à quel point Swing est mort et survit uniquement à l’état de zombie depuis huit ans principalement grâce à l'écosystème préexistant (NetBeans Platform, IntelliJ IDEA, etc.) qui végète depuis la date d'abandon (2008) sans nouvelle évolution. Donc, point de salut de ce côté-là non plus de toute manière.

Soit Oracle continue Java FX, soit il sort de son chapeau une nouvelle technologie (HTML5 quelque chose comme il l'a fait avec MAF https://en.wikipedia.org/wiki/Oracle...on_development), soit il le donne à la communauté, soit il n'y a plus de Java côté client desktop (et donc mobile/smartphone hors outils tiers style Codename One).

Sources :

• 2015/11/16 - When to use JavaFX instead of HTML par Dirk Lemmermann ;
• 2015/11/19 - Should Oracle Spring Clean JavaFX? par Shai Almog ;
• 2015/11/20 - “JavaFX Real-World Apps” JavaOne 2015 Presentation Online par Dirk Lemmermann ;
• 2015/11/23 - The future of JavaFX? par René Jahn ;
• 2015/11/30 - JavaFX is Here to Stay! par Dirk Lemmermann.