Quel avenir pour la boite à outils JavaFX, Oracle semble s'en désintéresser

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.

Ça serait vraiment dommage, JavaFX est une très bonne techno. La réalisation d'application est simple et le code est bien séparée de la vue (qui est généralement refourguée a un designer).

On dirait que Oracle aime se tirer dans les pieds... d'un coté il tape sur Google en mode "niaa tu utilise Java sans payer" et de l'autre il font tout pour couler Java...

Oui ,
ça serait vraiment dommage coté Java c'était la seule techno ( à ma connaissance) qui était un potentiel concurrent à WPF.
Retournons donc à Swing ou Swt :mouarf::mouarf:

Bref c'est une porte ouverte à considérer pour .NET Core.
Mais bon comme ils n'implémentent pas les technos d'UI sur les autres plateformes, Microsoft va encore louper le tir.

Sinon y'a Apache Pivot.

Mais bordel pourquoi Oracle a acheté Java !!!! Pourquoi Sun a accepté de se faire acheter ! Quel gâchis

Pour le travail nous sommes passé sur JavaFX, c'est vrai que graphiquement c'est plus jolie, en terme de fonctionnalité ca me parait complet aussi donc on arrive a transposer en javsfx tout ce qu'on avait en swing sans perte.

Par contre personnellement je suis passé sur ma propre librairie (Unlicense-lib) de widget :
Pièce jointe 197961 Pièce jointe 197963

Cela à plusieurs avantages :
- pas de soucis de license (domaine publique)
- collaboratif
- écrit en opengl
- presque compatible Android (demande encore un peu de travail pour etre compatble opengl 2/3 es)

AWT étant mort,
Swing un mort sous perfusion,
SWT trop compliqué/jni,
JavaFX en sursie avec des problemes de licenses et d'avenir,
QtJambi quasiment inutilisé.

Je pense avoir fait le bon choix en commencant ce nouveau toolkit il y a 3ans, il reste du travail mais c'est déjà utilisable, pour ceux qui veulent vraiment se libérer d'oracle, un petit coup de main n'est pas de refus. :aie:

L'article est très bon et résume bien la situation. Swing ??? mort! Donc on maintiens les app existantes et c'est tout. On à besoin de mobilité pour nos solutions? Directement les systèmes spécifiques sont pris en compte (Angulars) avec l'aspect serveur en java, pour l'instant (?). JavaFX inspire tellement peut de notre côté que cette techno n'est pas même pas abordé comme une possibilités pour les solutions mobilités. Je sent Oracle seul sur ce sujet, il n'y pas d'envie de faire progresser, de proposer et l'on ne parle pas de partager. C'est rageant tellement le potentiel techno est énorme.

Moi qui envisageais d'y passer.
C'est un peu la douche froide.

Il reste quoi :
- AWT mort et enterré
- Swing, je fais surtout de la maintenance applicative avec, et je ne dois pas être le seul.
swt, éventuellement mais je préfère les librairies standards
- Gwt, ce n’est pas exactement la même chose
- Qt Jambi, je n’y ai jamais cru. Et à ma connaissance il n’a jamais vraiment percé

On a vraiment l’impression que Oracle méprise la communauté Java.

A

j'ai toujours eu du swing à faire dans mes emplois ainsi que du web. On début j'ai trouvé swing un peu difficile quand on le compare à du vb, delphi... Cependant, ce n'est pas si complexe surtout quand on utilise un layout tel que MigLayout.

Cependant je trouve son nombre de composant assez pauve quand on le compare à Delphi. Aucun écosystème sur les composants ne s'est réellement créé.

Aujourd'hui je trouve qu'il y a de moins en moins d'emploi au niveau des applications de bureau. J'ai de nombreux collègue qui n'ont jamais touché à swing. Le marché s'est tourné vers le web.

Est-ce que vous continuez de faire de nouvelle application en Swing, JavaFX?

Même si Oracle partait de zéro, pour créer un nouveau framework, elle lui resterait que moins de 1 ans pour l'inclure dans Java 9, ce qui est trop peu... j'y crois pas trop.

Par curiosité, QtJambi semblait pas mal du tout (couche Qt qui assure)

Quelqu'un sait pourquoi le projet a été abandonné ?

surement qu'il avait peu de client et donc pas rentable pour l'entreprise.

Citation:

---

Envoyé par CoderInTheDark

Moi qui envisageais d'y passer.
C'est un peu la douche froide.

Il reste quoi :
- AWT mort et enterré
- Swing, je fais surtout de la maintenance applicative avec, et je ne dois pas être le seul.
swt, éventuellement mais je préfère les librairies standards
- Gwt, ce n’est pas exactement la même chose
- Qt Jambi, je n’y ai jamais cru. Et à ma connaissance il n’a jamais vraiment percé

On a vraiment l’impression que Oracle méprise la communauté Java.

A

---

Je l'ai jamais utilisé, mais il existe JVx
http://www.sibvisions.com/

qui supporte avec le même code créé

Swing
Applet, Webstart or Desktop

Vaadin
HTML5/Ajax

iOS und Android
Native App for Smartphone, Tablet

Citation:

---

Envoyé par gstratege

Mais bordel pourquoi Oracle a acheté Java !!!! Pourquoi Sun a accepté de se faire acheter ! Quel gâchis

---

Pour Sun, la raison est très simple: Pour les responsables de Sun, c'était se faire un peu de cash avec Oracle ou tout simplement faire faillite et tout perdre!!!

Sun MicroSystems a été à l'origine d'un nombre considérable de technologies libres (Java, MySQL, OpenOffice, etc.), mais on ne gagne pas sa vie avec le gratuit (chose que la communauté informatique a un peu oublié ces dernières années).


Pour Oracle, la raison est différente: Récupérer les marrons du feu et essayer de se faire du cash sur les investissements faits par d'autres (preuve en est l'attaque en justice de Oracle contre Google qui a utilisé des API Java dans Android)

Citation:

---

Envoyé par NSKis

Pour Sun, la raison est très simple: Pour les responsables de Sun, c'était se faire un peu de cash avec Oracle ou tout simplement faire faillite et tout perdre!!!

Sun MicroSystems a été à l'origine d'un nombre considérable de technologies libres (Java, MySQL, OpenOffice, etc.), mais on ne gagne pas sa vie avec le gratuit (chose que la communauté informatique a un peu oublié ces dernières années).


Pour Oracle, la raison est différente: Récupérer les marrons du feu et essayer de se faire du cash sur les investissements faits par d'autres (preuve en est l'attaque en justice de Oracle contre Google qui a utilisé des API Java dans Android)

---

De mémoire, La base de donnée Oracle reposait énormément sur Java, et Google était aussi candidat au rachat de sun. Oracle s'est juste payée une méga licence Java, ressource critique sur lequel repose son produit vache-à-lait.

J'ajouterais à ta liste VirtualBox qui lui n'a pas été abandonné ;)
Ni MySQL finalement, alors que c'était une grosse peur avant le rachat.

Il y avait aussi Solaris et son système de fichier ZFS qui ont fini sur un beau gachis....

Xerox et Sun sont a mon avis les deux boites privées ayant apporté le plus à l'informatique et elle resteront à jamais dans l'ombre et connus que des initiés....

Citation:

---

Envoyé par Vitofe

De mémoire, La base de donnée Oracle reposait énormément sur Java, et Google était aussi candidat au rachat de sun. Oracle s'est juste payée une méga licence Java, ressource critique sur lequel repose son produit vache-à-lait.

J'ajouterais à ta liste VirtualBox qui lui n'a pas été abandonné ;)
Ni MySQL finalement, alors que c'était une grosse peur avant le rachat.

Il y avait aussi Solaris et son système de fichier ZFS qui ont fini sur un beau gachis....

Xerox et Sun sont a mon avis les deux boites privées ayant apporté le plus à l'informatique et elle resteront à jamais dans l'ombre et connus que des initiés....

---

Sun a toujours été très médiocre en marketing. Elle a racheté de nombreuse entreprise, qui fonctionnait bien et les tuait à petit feu.... Tu les appelais pour savoir si le produit allait continuer, tu voulais du support... ils ne savaient pas trop.

Sun n'a pas su bien anticiper le marché. Leur OS Solaris et cpu sparc était en déclin, le marché à changé, mais pas eux, malgré que ça soit de bon produit. C'était devenu des marchés de niche. Il est moins cher de prendre du linux et de faire des clusters, il ne faut pas oublier le personnel (emploi), formation qui sont plus simple à dénicher pour linux.

Au niveau de Java, Sun n'a pas su le monnaitiser convenablement.

Avant l'achat de Sun, Oracle avait déjà une JVM, un serveur JEE et un outil de dévelopement. Maintenant elle a encore plus de produit. Oracle a cependant raté le virage mobile. Il aurait vraiment fallu qu'elle accélère ce marché après l'achat de Sun... Est-ce que Oracle sera se rattrapé?

Citation:

---

Envoyé par Vitofe

De mémoire, La base de donnée Oracle reposait énormément sur Java, et Google était aussi candidat au rachat de sun. Oracle s'est juste payée une méga licence Java, ressource critique sur lequel repose son produit vache-à-lait.

---

Le produit Oracle Database est développé en C, il ne repose sur la JVM que pour les procédures stockées écrit en Java (source). Pour ma part je n'ai jusqu'à présent vu que des procédures stockées écrits en PL/SQL en entreprise.

Citation:

---

Envoyé par NSKis

Sun MicroSystems a été à l'origine d'un nombre considérable de technologies libres (Java, MySQL, OpenOffice, etc.), mais on ne gagne pas sa vie avec le gratuit (chose que la communauté informatique a un peu oublié ces dernières années).

---

Sun n'est pas à l'origine de MySQL, c'est la société MySQL AB créé en 1995, racheté par Sun en 2008, qui à son tour se fait racheter par Oracle en 2010 (source). Le gratuit rapporte si tu vends du support, fait la promotion de tes autres produits, génère de la publicité, et possède de très bons avocats.

Citation:

---

Envoyé par NSKis

Pour Sun, la raison est très simple: Pour les responsables de Sun, c'était se faire un peu de cash avec Oracle ou tout simplement faire faillite et tout perdre!!!

Sun MicroSystems a été à l'origine d'un nombre considérable de technologies libres (Java, MySQL, OpenOffice, etc.), mais on ne gagne pas sa vie avec le gratuit (chose que la communauté informatique a un peu oublié ces dernières années).


Pour Oracle, la raison est différente: Récupérer les marrons du feu et essayer de se faire du cash sur les investissements faits par d'autres (preuve en est l'attaque en justice de Oracle contre Google qui a utilisé des API Java dans Android)

---

Si tu veux faire de l'argent avec le libre, c'est avec le support ou du dev qui apporte de la valeur ajouté que tu en fais... il y a plein de bon exemple...

red hat, suse, mysql...

Il me semble que le problème de javaFx c'est que ce n'est pas fait pour les développeurs, mais pour les designers d'interface utilisateur. Le code d’intégration façon xml est encore plus obscure que la verbosité d'un pur java sans représenter un avantage réel pour un développeur qui doit réapprendre un n-ième pseudo langage alors qu'il connait très probablement déjà les API graphiques du langage. En sus, les outils fournit par Oracle pour utiliser javaFx sont restés plutôt rudimentaires et longtemps truffés de sales bugs pouvant rendre les fichiers descripteurs d'interfaces inutilisables. L'ambition de cette technologie était pour l'essentiel de concurrencer FLASH et silverlight deux technologies que presque tout le monde aime à proclamer en état de mort clinique avec l'avènement du html5. En résumé nouveau langage en sur-couche sans intérêt avéré pour un dev + outils rudimentaires mal intégrés + bugs ingérables + techno concurrentes proches de l'obsolescence = ????? .

Citation:

---

Envoyé par marc.collin

Si tu veux faire de l'argent avec le libre, c'est avec le support ou du dev qui apporte de la valeur ajouté que tu en fais... il y a plein de bon exemple...

red hat, suse, mysql...

---

Tu oublies juste un petit détail dans ta belle théorie: On se fait de l'argent avec le libre en fournissant du support ou du dev A CONDITION... Que d'autres ont pris à leur charge la plus grande partie du boulot!!!

Si les RedHat, Suse avaient dû investir pour développer de zéro l'environnement Linux avec lequel ils se font de l'argent, il auraient assurément fini comme... Sun!!!

Récupérer le travail d'une communauté de bénévoles, y ajouter une couche de vernis et mettre son nom sur le produit final... Là oui... Le libre permet de faire de l'argent...

Citation:

---

Envoyé par 23JFK

Il me semble que le problème de javaFx c'est que ce n'est pas fait pour les développeurs, mais pour les designers d'interface utilisateur.

---

C’était vrai pour JavaFX 1 (c'est sur cela que le marketing de Sun s’était positionné d'ailleurs : ils ciblaient les designers) mais pas du tout pour JavaFX 2 et 8 je trouve : là, et depuis 2011, on est au même niveau que Swing ou AWT.

Citation:

---

Le code d’intégration façon xml est encore plus obscure que la verbosité d'un pur java sans représenter un avantage réel pour un développeur qui doit réapprendre un n-ième pseudo langage alors qu'il connait très probablement déjà les API graphiques du langage.

---

Le FXML est :

1. Complètement optionnel (tout comme l’était le FXD dans JavaFX 1 d'ailleurs).
2. Beaucoup plus lisible et beaucoup moins lourd que ses équivalents XML chez Adobe ou Microsoft. C'est juste du code Java sous forme XML, c'est super-hyper-simpliste par rapport a ce que propose la concurrence.
   (À noter que le FXD était quand mème plus simple que le FXML puisque c’était directement du JavaFX Script -un sous-ensemble, pas le langage complet- donc le même langage de programmation que celui employé par JavaFX 1 à l’époque).

Simplement on arrete pas de marteler qu'il faut toujours séparer la vue du modèle / contrôleur c'est pas pour rien car : c'est plus facile de manipuler visuellement le contenu d'un fichier FXML via SceneBuilder (ou a mano) pour faire des modifs dans une interface que d'aller bidouiller une classe Java de XXXXXX lignes de code de construction d'UI. Et je le répète, ça reste OPTIONNEL ! Si j'ai souvent opté pour FXML dans mes articles sur JavaFX c'est justement pour éviter de noyer l'article dans un flot de code Java uniquement destiné à placer un contrôle à un endroit précis de l’écran et ensuite à en changer le style / le LnF alors que le propos de l'article était bien ailleurs. C'est un peu comme si on reprochait l'usage d'un CSS (externe) dans du HTML : c'est quand même mieux quand le style est a part du contenu de la page, et la définition d'une <table> est plus facile à lire si y a pas des attributs de définition du style de 3km de long à chaque ligne.

Pour ce qui est de la qualité des produits Oracle sur JavaFX, là par contre effectivement, on a eut droit quand même a certains gros bugs tant sur le Rich Application Suite de JavaFX 1 que dans SceneBuilder pour JavaFX 2 & 8. Et Sun / Oracle etait long a sortir des patchs.

Je met plus ça sur le manque de moyens investis qu'autre chose : un truc choquant quand on va à la JavaOne c'est de se rendre compte combien certaines équipes d'Oracle sur certaines parties de Java sont toutes rikiti : j'ai l'impression que souvent on a des équipes de 2-8 personnes qui bossent sur un produit utilisé par des millions de personnes. Le gros des employé ça doit être des salesmen ou des gens du support ou écrivent la doc... J’étais un peu désolé de mon pétage de plombs lors de la JavaOne 2011 sur les 5 pauvres gars de l’équipe chargée l’équipe Java Deployment mais bon voila quoi c'est tout ce que méritait la qualité d'un produit comme Java Web Start...

Ça ne sera pas forcement mieux chez Gluon car ils ont annoncé que les releases gratuites seraient 2 fois par an. Seuls les clients payants ont droit a des releases plus souvent (la fréquence dépend de leur billing plan) ou alors il faut passer par la case build toi-même (Gluon reste OpenSource donc les sources de SceneBuilder et javafxport sont dispos).

Pour ma part, j'ai toujours fait du Swing, et comme je n'ai jamais eu affaire à une situation bloquante me forçant à en changer, j'y suis toujours. J'avais entendu ici ou là que JavaFX était l'avenir, mais il semble qu'il risque de devenir un zombie au même titre que Swing.

Du coup, y a-t-il vraiment une utilité à passer de Swing à JavaFX en l'état actuel des choses ?

Citation:

---

Du coup, y a-t-il vraiment une utilité à passer de Swing à JavaFX en l'état actuel des choses ?

---

Je ne crois pas tu as raison si ça continue comme cela.

Mickael

Citation:

---

Envoyé par Matthieu Vergne

Pour ma part, j'ai toujours fait du Swing, et comme je n'ai jamais eu affaire à une situation bloquante me forçant à en changer, j'y suis toujours. J'avais entendu ici ou là que JavaFX était l'avenir, mais il semble qu'il risque de devenir un zombie au même titre que Swing.

Du coup, y a-t-il vraiment une utilité à passer de Swing à JavaFX en l'état actuel des choses ?

---

Coté design , y'a vraiment pas photo coté JavaFx, j'ai énormément bossé sur swing ( malgré mon profil pro Microsoft).
J'ai toujours trouver le coté personnalisation des composants rebutant ( à l'époque je faisais du synth et du c++ avec jni pour les composants hautes performances).
J'arrivai à faire de belle applis en Swing mais cela me prenait du temps.

C'est vrai que depuis que je suis passé à WPF ( et un peu QT), le Java client lourds à beaucoup perdu dans mon estime :roll:.

Citation:

---

Envoyé par Vitofe

J'ajouterais à ta liste VirtualBox qui lui n'a pas été abandonné ;)
...
Xerox et Sun sont a mon avis les deux boites privées ayant apporté le plus à l'informatique et elle resteront à jamais dans l'ombre et connus que des initiés....

---

Non, en réalité, Sun n'a fait qu'acheter VirtualBox à Innotek GmbH ;)

J'aime beaucoup JavaFX. Je l'ai utilisé pour des applications personnelles. C'est assez simple à utiliser et permet d'avoir une application correcte assez rapidement.
Au boulot j'aimerais mieux faire du JavaFX au lieu du HTML/Javascript.
Je ne comprends pas pourquoi Oracle le laisse mourrir.

hello

Dirk L. fait partie de l'equipe que j'ai montée il y a un an (environ 10 a 15 personnes) , il a présenté un de "mes" projets JavaFx a San Francisco.

Les problemes rencontrés avec JavaFx sont les suivant et je ne vois rien qui s'ameliore avec le temps :
- peu d'expert JavaFx
- temps apprentissage long (bindings, observability, java8)
- pas mal de bugs encore
- pas de datatable digne de ce nom
- manque des objets graphiques
- trop bas niveau pour etre productif, manque framework construit au dessus de JavaFx
- lenteur sur les gros projets
- integration avec framework comme Spring difficile (ID par exemple)

JavaFX fut un choix décidé il y a 3 ans pour la stabilité de java // html+js+browser. Aujourd'hui , l'amertume est présente, surtout apres l'abandon de l'outil SceneBuilder. Je suis persuadé que JavaFX va etre laissé tel quel et ne va pas ou peu évoluer.

L'avenir du client lourd, je le vois sur les OS type Win/Linux uniquement en HTML
Reste Android et iOS qui auront leur propre client lourd

mes 2cts de contribution

J'étais un peu paniqué de voir que c'est excellent article écrit le 4 janvier et qui est quand même un fameux pavé dans la marre n'avait suscité aucune réaction avant le 14 janvier !!!
Je me suis dit "tout le monde s'en fout .... sauf moi" :mouarf:

J'espère franchement qu'il y aura un sursaut de la part d'Oracle ...

Cet article (qui est plutôt un compte rendu de ce qui s'est déroulé fin novembre) est le fruit d'une discussion interne qui tournait autour du fait que Mickael voulait lancer un débat sur l'avenir de JavaFX depuis septembre dernier. D'une part cela m'a pris pas mal de temps de visionner les présentations de la JavaOne autour desquelles nous voulions initialement articuler le débat (2h+ chaque) mais également la mise en place a été longue à cause de nos indisponibilité dans la vie-réelle (boulot, vacances, maladie, etc.). Or cette controverse qui s'est déroulée fin novembre a fait l'effet d'un mini-tremblement de terre qui a secoué la (petite) communauté de l'OpenJFX et donc nous avons jugé plus opportun d'articuler la discussion autour. Après tout, JavaFX reste encore le seul toolkit UI actuellement développé coté JavaSE par Oracle.

Le fait que le JDK 9 soit finalement reporté de plusieurs mois semble avoir un impact positif sur le futur JavaFX 9 et il semble que les équipes se soient désormais données comme but de doubler le nombre de fonctionnalités par rapport à ce qui avait été prévu initialement (pas grand chose à part la modularisation pour aller avec de concert avec le JDK 9).