Discussion :

[joseph_p]

Bonjour

Je me pose en ce moment la question suivante "quels sont les avantages et inconvénients respectifs d'eclipse rcp et swing en vue de faire du client lourd" ?

Pour eclipse RCP, je vois :
en + :
# mécanisme de mise à jour
# environnement préconstruit
# communauté active
en - :
# SWT : pb du look sur différents os
Pour swing je vois :
en + :
# portabilité
en - :
# tout à faire, pas de réutilisation possible

Qu'en dites vous ? Comment compléteriez vous cette liste ?

Merci d'avance
ZedroS

[sinok]

Pour swing:

Tout refaire c'est un peu limite quand tu vois le nombre de composants, de framework dispo sur le net rien que pour en citer deux gros:

• Swinglabs (en fait un regroupement de plusieurs projets dont swingx, JDIC...)
• l2fprod commons qui n'est pas mal dans son style

Sinon tu peux parfaitement faire du RCP en swing:

http://spring-rich-c.sourceforge.net/

Niveau communauté swing n'est pas dépourvu non plus, de loin pas...


Sinon vis à vis de SWT un petit désavantage à rajouter: la gestion manuelle de la mémoire... Au revoir garbage collector

[lunatix]

tu peux aussi utiliser netbeans platform (un equivalent de eclipse rcp)
tu as de nombreux tutoriels ici http://platform.netbeans.org/tutorials/index.html

[joseph_p]

Merci pour vos réponses.

En gros, si je récapitule, il y d'abord le choix entre SWT et Swing à faire, puis à regarder en détail les plates formes RCP à choisir.

Du coup, pour (tenter de) rendre intelligilible tout cela, j'ai fait ça :

1 - comparatif des bibliothèques de GUI en Java:

1.1 Swing
+ portable
+ purement java
+ fort soutien de Sun
+ communauté importante (le sous forum dédié à 4148 discussions)
- a connu des problèmes de lenteur (?) : sont ils vraiment résolus, notamment par rapport à SWT ?

1.2 SWT
+ fort soutien d'ibm
+ à la mode (me semble t il)
= portabilité "moyenne" réalisée via des implémentations systèmes
- pas de garbage collector : risques mémoire

2 - comparitif des widgets inclus de base et ceux disponibles par ailleurs

2.1 widgets inclus dans Swing
TODO

2.2 widgets additionnels à Swing

2.2.A swinglabs (http://swinglabs.org/)

Swinglabs regroupe plusieurs sous projets, voyons les plus significatifs (à priori).

2.2.A.1 SwingX

Ensemble de composants : fenêtre de login, astuce du jour, liste de choix avec auto complétion, calendrier, panneau avec bloc

(TaskPane), pour les autres composant le manque de doc fait que j'ai du mal à en comprendre l'intérêt
+ beau ?
+ ??
- manque de documentation
- ??

2.2.A.2 SwingWorker

Résoud la problématique du lancement de tâches dont le temps d'exécution est long. Sans Swingworker ces tâches font que

l'application ne répond plus.
+ utile
+ ??
- problème spécifique à Swing ??

2.2.A.3 JDIC

Ensemble d'outils pour déployer et intégrer du java sur un bureau, notamment : intégrer le navigateur web natif, lancer des

applications de la machine, intégrer l'application dans la barre des tâches, faire des installer JNLP (pour Java Web Start)
+ à priori plein de bones choses
+ ??
- ??

2.2.A.4 Wizard

Bibliothèque permettant de réaliser aisément des wizards.
+ ??
- petite communauté (peu de mails sur la mailing list developpeurs)

2.2.B l2fprod

TODO

2.3 widgets inclus dans Swt

TODO

2.4 widgets addtionels à Swt

??

3 - les RCP eux mêmes

3.1 Netbeans RCP
TODO

3.2 Eclipe RCP
TODO

3.3 Spring Rich Client
+ communauté non négligeable (1,005 posts sur le forum utilisateurs avec de nombreuses réponses, environ 130 mails/mois sur la mailing list developpeurs)
+ ??
- seulement en alpha
- pas de gui, tout dans le code
- peu de doc
- ??

J'avoue ne pas avoir fini, mais je pense vraiment continuer.

Autres points : toutes les remarques sont les bienvenues. Comme vous pouvez le voir j'ai tenté d'intégrer vos réponses et de les creuser.

Par ailleurs, je me pose la question de l'intégration de 3D dans ces différents RCP : avez vous des pistes/idées sur le sujet ?

Encore merci

ZedroS

[divxdede]

Pour un petit projet personnel je me suis basé sur Netbeans RCP
Justement pour être capable d'evaluer la plateforme.

cf: http://www.jprintcover.com

Si tu as des questions (pas trop compliqué) sur la plateforme pour ton comparatif, n'hezite pas.

[otsgd]

Salut,

J'ai bossé pendant 1 an sur un projet utilisant Eclipse RCP et y a du pour et du contre :
- La modularité étant le maitre mot, il convient de bien penser son architecture de plugins, les interractions sont complexes à gérer et non débuggé par Eclipse (au format xml). Le nommage doit être d'une cohérence sans faille.
- Les fonctionnalités (mises à jour, préférences, worskpace, vue, aide, éditeurs ...) directement disponibles sont très utiles et plutot bien pensées.
- La doc en français est quasi inexistante dès lors qu'on rentre dans les détails, tout est en anglais et pas toujours évident à trouver.
- Le code source d'Eclipse que l'on parcourt nécessairement lorsque l'on fait une appli RCP (pour voir comment ils font tel truc) n'est pas documenté et pas facile à suivre.
- notre entreprise avait apprécier la qualité graphique et ergonomique des résultats
- développement rapide de certaines fonctionnalités complexes (tableaux, arbres, tris, recherche, complétion ...
- Malgré ce qu'on pensait (jar de SWT différents selon les plateform), on avait eu certaines supprises suivant les OS, la présentation était parfois mal faite sous Windows ou sous Linux.

Voilà une idée générale.

[adiGuba]

Salut,

- a connu des problèmes de lenteur (?) : sont ils vraiment résolus, notamment par rapport à SWT ?

Les performances de Swing se sont nettement améliorer depuis Java 1.2. De plus la plupart de ces "problèmes" venait du fameux bugs des carré gris, causé à cause d'une mauvaise gestion des threads...

2.2.A.2 SwingWorker

Résoud la problématique du lancement de tâches dont le temps d'exécution est long. Sans Swingworker ces tâches font que

l'application ne répond plus.
+ utile
+ ??
- problème spécifique à Swing ??

Ce n'est pas un problème spécifique à Swing !
La plupart des API graphique sont mono-thread, et implique donc deux choses :

• l'utilisation de thread séparé pour les tâche de fond.
• l'utilisation du thread qui gère l'UI pour mettre à jour l'affichage.

C'est la même chose pour SWT d'ailleur, et les méthodes asyncExec() et syncExec() de la classe Display de SWT correspondent aux invokeLater() et invokeAndWait() de la classe SwingUtilities...

Il me semble d'ailleur que SWT est encore plus sévère en provoquant une exception si on modifie l'UI depuis un mauvais thread...

Sinon pour SwingWorker je rajouterais :
+ En standard dans Java 6
+ Simplifie grandement la gestion des threads.


Enfin pour JDIC, il faut quand même rajouter ceci :
+ Certaine fonctions (ouverture du navigateur/client email, ouverture des fichiers avec le programme associé, intégration dans la barre des tâche) sont déjà intégré dans Java 6 en standard !
- La portabilité n'est pas parfaite, notamment sous Mac

L'autre avantage de SWT (pour moi), c'est justement qu'il s'adapte au look&feel de l'OS.

Swing peut également s'adapter au Look de l'OS en utilisant le LookAndFeel système. Il suffit de rajouter une ligne de code (5avec le try/catch qui va avec) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
		try {
			UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
		} catch (Exception e) {
			// IGNORED !
		}

a++

[n!co]

J'ai aussi du faire ce choix pour l'application que je développe.

Pour rajouter un petit arguement au débat, si tu veux faire un peu mumuse avec tes composants graphiques, c'est imposible avec SWT. Il n'y a pas de notion d'héritage juste de la composition de plusieurs composants.

[olitank]

Les clients RCP offrent des applications presque complètes, à personnaliser pour obtenir sa propre application.
C'est une bonne approche mais il existe une autre approche consistant à générer et à personnaliser via la réflection un prototype d'application (voir ReflectionUI).