Vous utilisez SWT/JFace ou Java FX ? Partagez votre expérience

Êtes-vous plus Eclipse SWT/JFace ou Java FX ?
Les choix stratégiques d'Oracle pourraient relancer le débat

Avant l'arrivée de JavaFX et quand la boîte à outils Swing était largement mise en avant par Sun, la question se posait souvent sur le choix entre Swing et SWT/JFace la boîte à outils fournie par la plateforme Eclipse.

Aujourd'hui Swing est en perte de vitesse et Oracle souhaite la remplacer par Java FX.

Allons-nous voir apparaître un nouveau dilemme sur le choix de ces boîtes à outils Java pour le développement d'application de bureau ?

La rubrique Java de Developpez.com vous propose aujourd'hui de partager votre opinion et votre expérience sur ces deux boîtes à outils que sont Java FX et SWT/JFace.

:fleche: Êtes-vous plus Java FX ou SWT/JFace ?

Si je me fie au autre d'emploi de l'époque, le choix ne se posait même pas, c'était swing.

Je crois que swing est en perte de vitesse tous simplement car le web tend à dominer au niveau du développement.

Il suffit de regarder les offres d'emplois....... ça tourne majoritairement autour du web.

La vrai question je crois est si Oracle va investir et pousser cette technologie?

Il reste à avoir de bon éditeur graphique.

je crois que j'ai trouvé le graal , de l'IHM java !!!

http://www.VAADIN.com

ça se code comme du swing,
et ça se comporte comme du RIA super classe
ça fonctionne dans un navigateur , de ie6 a x pour les composant basic.
ca fonctionne sur le mobile
et ca peut fonctionner en standalone avec phonegap (pas encore testé)

le graal pour un éditeur de logiciel qui souhaite couvrir tout les supports.

c'est basé sur gwt.

Philippe

Les DSI ont pratiquement déjà sceller le fait de ne plus installer d’application sur le poste de travail, cela prend plus de temps d’installer 200 poste à distance que de déployer une application sur un serveur, sans parler de la maintenance et des migrations d’OS sur les poste de travail, donc, à moins de s’intégrer dans un client léger (ou client riche comme disent certains), je ne voit SWING ou autre technologie d’IHM lourde que perdre du terrain face à la richesse du client léger.

Le cloud veux aussi faire un ravage et imposer encore plus une dictature du tous centraliser et accessible uniquement via client léger, mais cela touche gravement à la définition du poste de travail en lui-même qui pourrais ce voir transformer en interface de travail qui fournie un navigateur et une connexion réseau.

En somme, la tendance reste plus en faveur du web que du client lourd, à moins de voir surgir de nulle part des outils permettant de normalisé l’intégration de client lourd plus facilement au sein d’un SI.

Ayoub.

Citation:

---

Envoyé par pdefert

je crois que j'ai trouvé le graal , de l'IHM java !!!

http://www.VAADIN.com

ça se code comme du swing,
et ça se comporte comme du RIA super classe
ça fonctionne dans un navigateur , de ie6 a x pour les composant basic.
ca fonctionne sur le mobile
et ca peut fonctionner en standalone avec phonegap (pas encore testé)

le graal pour un éditeur de logiciel qui souhaite couvrir tout les supports.

c'est basé sur gwt.

Philippe

---

Attention toutefois: avec Vaadin aucun traitement est réalisé côté client, tout se passe côté serveur. Il faut donc pouvoir tenir la charge.

Citation:

---

Envoyé par ithel

Attention toutefois: avec Vaadin aucun traitement est réalisé côté client, tout se passe côté serveur. Il faut donc pouvoir tenir la charge.

---

c'est plutôt pas mal que de tous gérer coté serveur, ça évitera tous le débogage coté client des requêtes Ajax et veiller au chargement des objet du DOM, après j'ai pas encore tester, mais j'ai déjà utilisé Extjs et GWT, et c'est beaucoup mieux que du swing, l'avantage aussi des CSS fait la différance quant même :ccool:

Ayoub.

Citation:

---

Envoyé par pdefert

je crois que j'ai trouvé le graal , de l'IHM java !!!

http://www.VAADIN.com

ça se code comme du swing,
et ça se comporte comme du RIA super classe
ça fonctionne dans un navigateur , de ie6 a x pour les composant basic.
ca fonctionne sur le mobile
et ca peut fonctionner en standalone avec phonegap (pas encore testé)

le graal pour un éditeur de logiciel qui souhaite couvrir tout les supports.

c'est basé sur gwt.

Philippe

---

c'est pas nouveau
dans le même genre mais orienté client il y a ext-gwt

la version actuel de vaadin ne supporte qu'une architecture serveur
la version 7 apportera le côté client
les avantages/défauts des deux pourront être combiné

Citation:

---

Envoyé par moustic98

c'est plutôt pas mal que de tous gérer coté serveur, ça évitera tous le débogage coté client des requêtes Ajax et veiller au chargement des objet du DOM, après j'ai pas encore tester, mais j'ai déjà utilisé Extjs et GWT, et c'est beaucoup mieux que du swing, l'avantage aussi des CSS fait la différance quant même :ccool:

Ayoub.

---

il y a la sécurité aussi
après je crois qu'on développe pas de la même façon...... il faut faire beaucoup plus attention au ressource

Citation:

---

Envoyé par marc.collin

c'est pas nouveau
dans le même genre mais orienté client il y a ext-gwt

la version actuel de vaadin ne supporte qu'une architecture serveur
la version 7 apportera le côté client
les avantages/défauts des deux pourront être combiné



il y a la sécurité aussi
après je crois qu'on développe pas de la même façon...... il faut faire beaucoup plus attention au ressource

---

j'ai pas bien compris ce que tu veux dire par sécurité 8O

Citation:

---

Envoyé par moustic98

j'ai pas bien compris ce que tu veux dire par sécurité 8O

---

En autre les framework orienté serveur n'expose pas la logique du côté client.


je t'invite à te renseigner sur les frameworks orienté serveur, client, c'est assez intéressant et instructif.

Pourrais-tu expliciter un peu + quelle partie du code "logique" on va retrouver coté client et qui met en péril la sécurité ?

Il y a eu une belle conf (dispo sur Parley's) au BreizhCamp sur JavaFX 2. depuis que le l'ai vue, j'y crois!

Citation:

---

Envoyé par bugsan

Pourrais-tu expliciter un peu + quelle partie du code "logique" on va retrouver coté client et qui met en péril la sécurité ?

---

ton code métier, tes traitements, tes validations
tu peux très bien faire une application avec la majorité du traitement du côté du client

j'ai récemment vu un système où il était assez simple de falsifier des données....

une fois que tu recevais les données en local, tu éditais la pages par exemple tu changeais le id qui était 3 par 5.... et écrasait ainsi les données du id 5

faudrait peut-être démarrer un autre discussion...... car c'est pas vraiment en lien avec le sujet initial

il y avait eu des démos de javafx sous ios et android.
ça pourrait contribuer à faciliter le développement

la roadmap de javafx
http://www.oracle.com/technetwork/ja...p-1446331.html

JavaFX Scene Builder afin de créer des interfaces simplement
http://www.oracle.com/technetwork/ja...ols/index.html

Citation:

---

Envoyé par marc.collin

ton code métier, tes traitements, tes validations
tu peux très bien faire une application avec la majorité du traitement du côté du client

j'ai récemment vu un système où il était assez simple de falsifier des données....

une fois que tu recevais les données en local, tu éditais la pages par exemple tu changeais le id qui était 3 par 5.... et écrasait ainsi les données du id 5

faudrait peut-être démarrer un autre discussion...... car c'est pas vraiment en lien avec le sujet initial

---

Je suis tous à fait d'accord avec toi, l'encapsulation permet de pas trop tombé dans le panneau, mais faut aussi mettre toutes la logique de traitement coté serveur, sinon faut lancer un autre débat et ne pas trop polluer celui-ci :ccool:

je fais malheureusement du swing actuellement que sous Java 1.5 donc javafx ce n'est pas pour tous de suite.

si c'est disponible tel qu'il avait été au départ sur les tv, mobile et bureau, ça permettrait de toucher un large public d'un seul coup
sans compté que ça sera inclus dans la jvm au lieu d'un produit externe tel que swt

Pour en revenir au sujet initial, j'ai eu de (très) mauvaises expériences avec SWT.
Si on fait une IHM fixe (équivalent web 1.0), ça doit pouvoir être jouable, dès qu'on tombe dans le dynamique (équivalent web 2.0), c'est l'anarchie totale.

À mon avis sur SWT, la plus grosse erreur qui a été faite est la nécessité de construire tous les widgets en connaissant à l'avance le parent : Widget(Widget parent, int style).
Il est impossible de reparenter un composant après sa création !
Des cas d'utilisation classiques et simples mais qui deviennent juste infernaux à faire en SWT : gérer des éléments dans 2 colonnes et changer un élément de colonne, trier un tableau d'éléments par rapport à une colonne…

À noter aussi des choses assez étranges, comme des centaines d'attributs tous stocker sous la classe SWT et utilisés comme 2nd paramètres dans les constructeurs, mais sans aucune logique (ça va de la gestion des bordures aux clics de souris en passant par la police à utiliser) ni type-safety (tous les composants n'acceptent pas tous les paramètres disponibles et planteront lamentablement à l'exécution si on en passe un mauvais).

Pour finir, de jolies fuites mémoire sur la gestion des polices, des images ou des couleurs, un concept du MVC à la limite du foireux…

À sa décharge, je me servais de SWT de la même manière que Swing, c'est-à-dire sans les surcouches type JFace ou RCP.
Peut-être que c'est plus utilisable avec ce genre de techno, mais en natif, on ne m'y reprendra plus !

Avec tout ça, il faut encencer les développeurs d'Eclipse, qui arrivent quand même à faire un sacré boulot avec un truc qui sent aussi mauvais =)

Niveau JavaFx, jamais vraiment pratiqué, mais ça me semble très prometteur, avec des fonctionnalités vraiment sympa (bind powered !!!).
Je pense que ça sera ma prochaine expérimentation sur mon prochain projet pro qui me le permettra.

Jai commencé lentement le javafx avec le scene builder, cest tres different de swing, le potentiel est enorme mais pour l'instant les outils ne sont pas au point et la documentation sur le web est tres minime.

Je suis deja impatient de voir la suite et d'en apprendre davantage, pour l'instant il est un peu tot pour me forger un opinion definitive.

swing est encore vivant...

J'ai trouvé miglayout assez sympa mais commercial je crois qu'il y a une version free.
Je corrige c'est un layout manager très complet. La version que j'utilise dans l'idée "JComponentBuilder" (éditeur d'interfaces graphiques) je pense est commerciale mais les binaires livrés avec sont libres (compile, runtime).
C'est la première fois que j'arrive à faire une gui.
Ça existe pour Swing et javafx génération de code pas parfaite mais quand on a pris en considération les limites et le fonctionnement il y a moyen de faire quelque chose sans tout coder péniblement. Ça existe aussi pour Javafx mais ça fait 8 mois que je n'y ai plus touché because maladie hôpital.
J'ai essayé aussi JavaFX mais j'ai "décroché" à mon âge je devrais pas dire comme ça mais ce qui m'est arrivé était ultra violent. Je vais m'y remettre. Ce que j'ignore et que je n'ai pas su développer comme compétence c'est la fluidité et la réactivité dans l'exécution des tâches. Bien threader, choisir le bon ensemble de composants et faire rouler...

Pour les taches de fond c'est par la ;)

J'ai eu une assez bonne expérience avec JavaFX. A commencé le développement de l'interface graphique en Java il y a quelques mois après une certaine expérience avec l'interface graphique python (pyqt5 et tkinter). Comparé à eux, JavaFX est comparable à mon avis.