Discussion :

[benoit-v]

Bonjour à tous,

actuellement en L3 MIAGE en alternance, j'ai comme projet d'entreprise de réaliser un module utilitaire (gestion de présences, de contrats, etc), à coder dans le langage de mon choix.
Je suis personnellement plus à l'aise en Java, c'est donc vers ce langage que je pense me tourner.
Seulement voilà, je ne sais pas trop si je dois utiliser swing, javaFX ou encore JEE (JEE en dernier recours, ils préfèrent une application exécutable).

Après quelques recherches et autres tests, je me suis rendu compte que swing était plutôt laid, et que javaFX permettait de réaliser de bien plus belles applications.
J'ai donc décidé de creuser dans cette direction, mais après mes recherches sur FX, je me suis rendu compte que les avis des développeurs divergeaient : certains disent qu'il est trop lent, qu'il faut installer des "bibliothèques" assez lourdes sur les machines utilisateurs..

J'aimerais avoir des avis récents sur le sujet, car je ne veux pas me tromper et changer d'avis en cours de route. C'est une décision importante à prendre, le projet est assez gros et important pour l'entreprise.

Merci d'avance pour vos retours.
Cordialement,
Benoit

[joel.drigo]

Salut,

Je ne peux me prononcer sur JavaFX parce que je n'ai jamais travaillé avec. Je travaille plutôt en SWT/JFace. Mais pour avoir développer sous Swing, avec Jide notamment, je ne comprends pas cette assertion récurrente comme quoi Swing serait laid. Sans parler de subjectivité de cet avis, et si je partage cet avis sur certains vieux "Look And Feel" de base, il existe de nombreux Look n Feel de qualité et qui rendent l'apparence des applications indissociable des applications natives, à quelques détails près parfois, qu'on peut ajuster. En particulier, avec Windows et Macintosh (je ne peux pas parler d'environnement linux). Et si le genre d'interfaces qu'on réalise en Swing est "classique", en comparaison de ce qu'on peut trouver sur les interfaces modernes, en particulier sur le web, ou dans des applications particulières (genre iTunes par exemple, ou Picasa... qui dérogent aux standards de l'environnement graphique), on peut réaliser tout ce qu'on voit dans ces interfaces en AWT/Swing.

[benoit-v]

Hmm, en effet, mes propos ont peut-être été un peu durs avec SWING.
Je ne connais pas beaucoup cette bibliothèque graphique, je me suis surtout servi des avis des internautes et du peu d'exemples d'applications SWING que j'ai trouvé sur le web pour le juger. Et puis j'ai lu un peu partout qu'il allait être délaissé au profit de javaFX, c'est pour toutes ces raisons que j'ai abandonné mes recherches à ce propos.

[plawyx]

J'ai donc décidé de creuser dans cette direction, mais après mes recherches sur FX, je me suis rendu compte que les avis des développeurs divergeaient : certains disent qu'il est trop lent, qu'il faut installer des "bibliothèques" assez lourdes sur les machines utilisateurs..

J'ai plusieurs applis javaFX qui tournent sur des RaspberryPI 2 , sans remarque particulières des utilisateurs sur la lenteur.

[bouye]

Plutôt que de parler de ce qui est mieux ou laid je préfère faire l’état actuel des choses (de mon point de vue) :

AWT

• - Plus aucun développement officiel (excepté patch de gros bugs, correctifs dans l'infrastructure Java2D, etc.)
• ~ Écosystème ???? La dernière fois que j'ai fait de l'AWT a plein temps c’était en 1998, je n'ai aucune idée si il y a un écosystème conséquent dans ce domaine.

Swing

• - Plus aucun développement officiel (excepté patch de gros bugs, correctifs dans l'infrastructure Java2D, etc.)
• - Le système de LnF. Par ce qu'on aura beau me dire que Nimbus machin truc chouette oui mais non. Y a des super LnF tant qu'on reste sur des composants standards. Créer de nouveaux composants et ajouter le support d'un LnF existant pose problème. Créer un nouveau LnF est une sinécure.
• -Le support du hdpi / retina n'est pas pris en charge nativement. C'est pas impossible de l’implémenter mais c'est pas forcement évident non-plus sans devoir tout réécrire.
• + Énorme écosystème... principalement en entreprises (parce que bon comme tout le monde le sait, coté client, Java...).
• + On peut utiliser JavaFX dans Swing (pour les nouveautés : media, HTML5, etc.)
• + Java2D en mode dessin manuel dans un Graphic2D c'est cool. De ce coté la même l'API équivalente dans JavaFX n'est pas aussi bien je trouve.
• - Oui mais voila c'est pas pour autant qu'on a forcément besoin de faire du Java2D partout tout le temps des qu'on veut changer l'apparence d'un truc.
• + NetBeans Platform.

JavaFX

• + Quoi qu'on puisse en dire (même moi ; voir plus bas) c'est activement supporté par Oracle actuellement / pour le moment.
• + On peut utiliser du Swing dans du JavaFX (pour intégrer des contrôles et applications legacy dans une app en cours de modernisation)
• + Le système de LnF : c'est du CSS. Mise à part si je veux changer réellement le skin (c-a-d la classe Java qui gère l'agencement des sous-parties ou encore le comportement face aux saisies), tout ce que je dois faire pour modifier l'apparence d'un contrôle c'est modifier un !@#!@ de fichier CSS.
• + JavaFX supporte déjà le hpi / retina de manière partielle (j'y reviendrai probablement un de ces 4 dans un blog post que le chef de section veut me faire publier mais j'attends de voir si des développements sont prévus pour le JDK9 et aussi de pouvoir visionner la session qui a eut lieu a ce sujet a la JavaOne 2015).
• + Support du tactile (eat that Swing!).
• + Le SceneGraph : j'ai fait du Swing a plein temps de 1998 à 2010 et j'ai surchargé je ne sais combien de centaines (milliers ?) de paintComponent() sur des classes qui extends JPanel ou extends JComponent mais je suis désolé à partir de JavaFX 2, l'API pour monter une GUI est bien mieux fichue et moderne que ce que Netscape + Sun ont pu pondre en 1996-1997. Note : ce n’était pas le cas dans JavaFX 1/JavaFXScript qui m'a souvent causé des maux de tête à cause du layout ; maux que j'ai régulièrement reporte sur ce forum.
• - L’écosystème est plus petit... mais il existe. On peut donc trouver des contrôles additionnels, payants ou gratuit, mais globalement le choix est quand même bien moins impressionnant que pour Swing.
• - Après nous avoir bien fait ierch avec le support de la JavaTV (lol) dans JavaFX 1/JavaFXScript (ce qui a occasionné beaucoup de retard et autres features passées a la trappe) Oracle a complétement raté le coche du support mobile alors qu'Apple lui avait ouvert grand la voie en changeant sa license de développement pour iOS pour permettre d'utiliser des langages et outils autres que ObjectiveC. La faute aux avocats et au procès d'avec Google probablement.
• - Il manque encore pas mal de trucs pour s'affranchir complétement de AWT/Swing/Java2D. Notamment pour les I/O sur les images (car ImageIO se base sur les images Java2D) ce qui a des implications sur le support hdpi / retina lors du chargement manuel des images ou encore sur le fait qu'une app JDK9 qui veut lire/écrire des images va devoir empaqueter tout le module AWT/Swing/Java2D juste pour ça.
• - Performances du SceneGraph : clairement tout le monde s’accorde à dire que les performances étaient meilleures dans le JDK7+JavaFX 2.2 que dans JavaFX 8. Le clou a encore plus été enfoncé lors de la sortie de JavaFX 8-60 (et 65-66) qui offre des performances exécrables (et des bugs, cf WebView avec des ressources embarquées). Un trou de performance a été découvert récemment mais reste a savoir quand il sera corrigé ou s'il faudra attendre le JDK 9 ou si un backport verra le jour sous peu.
• - Oracle implémente des nouveautés a la vitesse d'un escargot. Ah oui parce que toutes les ressources de développement d'Oracle sont actuellement monopolisées par la finalisation du JDK 9 mais aussi parce que bon... on ne sait justement pas trop ou ils veulent aller coté client (probablement nulle part en fait - oui je sais que c'est contradictoire avec ce que j'ai écrits en 1er point).
• + NetBeans Platform.

SWT

• + On peut utiliser JavaFX dans SWT (pour les nouveautés : media, HTML5, etc.)
• + Eclipse Platform ?
• ~ Bizarrerie de la nature : un contributeur/intervenant majeur de SWT cherchait a effectuer le rendu de SWT via JavaFX il y a quelques années. Je ne sais pas ou en sont ses travaux mais il avait réussi a faire qu'une version préliminaire d'Eclipse soit rendue via JavaFX plutôt que via les contrôles natifs.
• ~ Pour le reste aucune idée ; je n'ai jamais utilisé SWT.

[benoit-v]

Merci pour vos retours, je pense m'orienter vers javaFX mais je vais étudier ça de près

[bouye]

Ah et si vous voulez un avis plutôt nuancé (et qui va dans le sens du mien) sur la question, je vous conseille ce blog post. Ce post pointe egalement vers des posts exposant les avis extrêmes (des deux cotés), comme ça vous avez un tableau plutôt complet de la situation.

En résumé, c'est Oracle qui m... de toute manière et tout le processus de développement était bien plus ouvert jusqu’à cette année. C'est quand même un comble que le passage vers le bug tracker de l'OpenJDK rende les choses moins open sources et moins interactives (avec les devs) qu'elle ne le furent dans le passé, mais c'est ainsi...