Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par bouye

43PARTAGES

4  0 
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 :

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Vitofe
Membre régulier https://www.developpez.com
Le 14/01/2016 à 15:35
Citation Envoyé par NSKis Voir le message
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....
3  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 15/01/2016 à 5:32
Citation Envoyé par 23JFK Voir le message
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.

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).
3  0 
Avatar de robertledoux
Membre habitué https://www.developpez.com
Le 14/01/2016 à 9:17
Ç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...
1  0 
Avatar de gstratege
Membre habitué https://www.developpez.com
Le 14/01/2016 à 12:22
Mais bordel pourquoi Oracle a acheté Java !!!! Pourquoi Sun a accepté de se faire acheter ! Quel gâchis
1  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 14/01/2016 à 17:19
Citation Envoyé par Vitofe Voir le message
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 Voir le message
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.
1  0 
Avatar de chinagirl
Nouveau membre du Club https://www.developpez.com
Le 18/01/2016 à 17:50
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.
1  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 14/01/2016 à 9:39
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

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.
0  0 
Avatar de dwarfman78
Nouveau membre du Club https://www.developpez.com
Le 14/01/2016 à 11:41
Sinon y'a Apache Pivot.
0  0 
Avatar de eclesia
Rédacteur https://www.developpez.com
Le 14/01/2016 à 12:56
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 :


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.
0  0 
Avatar de youx21
Membre du Club https://www.developpez.com
Le 14/01/2016 à 13:44
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.
0  0