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.

[Nico73]

Bonjour,

Je connais Eclipse RCP depuis début 2004 alors que la version 3.0 d'Eclipse était encore en cours de réalisation (1ère incorporation du RCP). Et c'est vrai qu'à l'époque il n'y avait pas beaucoup de documentation...

Aujourd'hui je trouve que de ce point de vue là, ça a pas mal évolué. Le tutoriel de base (en 3 étapes) est assez simple à suivre.
Lien vers la première étape du tutoriel

Evidemment le souci majeur est pour trouver de la documentation en français. Je crois que des bouquins en français sont quand même sortis à propos d'eclipse et en particulier du RCP.

A part ça, j'avoue ne pas connaitre les autres clients riches. Je me demande s'ils ont atteint la même maturité qu'eclipse RCP (ils l'ont peut être dépassé ?). Je trouve quand même l'interface d'eclipse très agréable, et pouvoir reprendre les concepts de perspectives, vues, éditeurs dans eclipse RCP est un plus à mes yeux.

Pour préciser, si tu choisis eclipse RCP, tu feras forcément du SWT (et JFace, la couche supérieure). Par contre, tu peux intéger des composants Swing dans un composant SWT (je le fais avec des composants JFreeChart et JGraph).

Personnellement, j'ai une mauvaise image de Swing que je trouve un peu vieillo. Mais j'ai lu que Sun avait rebossé dessus pour Java 6. De plus, quand je l'utilisais, je ne connaissais pas les Look and Feel qu'il était possible d'intégrer (à mon gout, le look and feel de base est laid et fait assez amateur).

Pour les adeptes de Swing, ne prenez pas ça pour une attaque, j'ai juste eu une mauvaise première expérience, et je suis prèt à changer d'avis

Nico

[joseph_p]

Merci pour ces réponses.

Une petite question : comment se passe les mises à jour de la plate forme (netbeans/eclipse) pour les applications construites dessus et déployées sur des postes ? Est ce transparent, y a t il blockage à un certain niveau, faut il tout retester avant ?

Merci d'avance
ZedroS

ps : Netbeans RCP a aussi l'air pas mal, maintenant j'suis encore en train de regarder de ci de là ^^

[divxdede]

Par rapport a ton début de comparatifs

JDIC: Multi-plateforme grace à la version cross-plateforme. Cette version charge au sein du classpath de l'application le jar "stub" propre à l'OS.
Problème ? Oui avec Netbeans RCP car Netbeans n'utilise pas un URLClassLoader necessaire au chargement du Stub de JDIC.
Donc JDIC Cross-Plateforme incompatible avec Netbeans RCP

Les Wizard de SwingX sont peut utile du moment que tu utilises un RCP car la pluspart intègre leur propre API de Wizard.

SwingX en soi est une trés belle API (propre et efficace). Si tu t'orientes sur une application Swing, cette librairie peut rapidement devenir un "must-have".

[Jense]

On utilise Eclipse RCP depuis un peu plus d'un an.
Je pense que c'est le RCP le plus abouti (puisqu'il est le plus vieux).
D'ailleurs NetBeans propose maintenant le sien et j'ai lu quelque part qu'une plateforme sera proposée dans Java 1.7

Côté pratique, je suis vraiment convaincu par le RCP. Le système de plugin proposé par Eclipse est très intéressant dès lors on développe plusieurs application. Les plugins seront donc réutilisés sans aucune modification (par exemple pour la log, les graphs, la 3D, etc... le tout accompagné des écrans de préférence et autres wizards qui seront automatiquement insérés)
D'ailleurs les plugins proposés par Eclipse ou la communauté open-source sont de plus en plus nombreux.

Le sytème des vues/perspectives a été très vite apréhender par les utilisateurs. Ils adorent pouvoir adapter leur application en fonction de leurs besoins.

On utilise Java Web Start pour le déploiement. Ca ne pose aucun problème et permet d'avoir toujours la dernière version sur le poste.
Cependant le système d'update proposé par Eclipse est très intéressant puisqu'il permet aussi les updates automatiques.

Côté développement, SWT/JFace impose une (courte) période d'adaptation. Mais les principes Java sont largement respectés. Le seul inconvéniant est de gérer les resources système (images, fonts et couleurs). Mais là aussi, c'est facilement gérable avec, par exemple, une classe ResourceManager.
L'autre avantage de SWT (pour moi), c'est justement qu'il s'adapte au look&feel de l'OS. L'utilisateur a vraiment l'impression d'avoir une appli qui s'intègre à son environnement et qui a la même tête que son navigateur ou que son exporateur de fichier.

Bref, on utilise Eclipse RCP, parcequ'on pense que c'est le plus abouti et le plus vivant. Mais on garde toujours un oeil sur les propositions concurentes.

[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.

[lunatix]

il y a aussi d'autres solutions plus legeres que le RCP complet
voir http://www.clientjava.com/blog/2006/...937901773.html
ou un simple docking framework peuvent aussi etre suffisants

[divxdede]

il y a aussi d'autres solutions plus legeres que le RCP complet
voir http://www.clientjava.com/blog/2006/...937901773.html
ou un simple docking framework peuvent aussi etre suffisants

A ce sujet j'ai cru comprendre que le Docking System de Netbeans s'externalisait en un projet appelé JDocking. Wait & See.

https://jdocking.dev.java.net/

[lunatix]

super ca ! j'avais suivi un post sur java.net ou un mec disait qu'il avait extrait ca de netbeans, mais pas vu qu'il ouvrait un projet. Je vais tester tient

merci pour l'info

[joseph_p]

Chtite question, surtout pour du Swing seul mais pourquoi pas pour du SWT : existe t il des composants permettant la mise à jour automatique de prédéfinis ?

[divxdede]

Chtite question, surtout pour du Swing seul mais pourquoi pas pour du SWT : existe t il des composants permettant la mise à jour automatique de prédéfinis ?

la mise à jour de prédefinie ? Qu'entends tu par là ?

Si tu parles de préferences utilisateur, il existe dans Java 1.5 le packages java.util.prefs

Tu peu (en exemple) enregistrer une préference utilisateur de cette manière:

Code :

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

1
2
Preferences prefs = PreferencesFactory.userRoot();
prefs.putString("locale", Locale.getDefault().getISO3Language() );

Et charger une preference utilisateur comme suit:

Code :

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

1
2
3
Preferences prefs = PreferencesFactory.userRoot();
          String localName = prefs.getString("locale", Locale.getDefault().getISO3Language() );
          ....

[joseph_p]

Je me suis mal exprimé. Je parle de mise à jour de l'application (update), genre changer une partie de l'interface ou du code métier.

Perso je vois ça comme une fonctionnalité quasi incontournable et assez dure à mettre à en place.

Je ne suis pas certain que Java Web Start résolve tous ces problèmes pour une application purement Swing/SWT, notamment vu que les RCP tels Netbeans/Eclipse proposent un module de mise à jour.

[lunatix]

java web start peut effectivement de mettre a jour ton application facilement. du coup, si tu changes un jar, il le mets a jour automatiquement.

Les deux RCP sont plus evolués, puisqu'ils permettent d'aller chercher des plugins sur differentes url, voir meme en local. c'est plus complexe, mais plus souple c'est sur.

[divxdede]

Je me suis mal exprimé. Je parle de mise à jour de l'application (update), genre changer une partie de l'interface ou du code métier.

Perso je vois ça comme une fonctionnalité quasi incontournable et assez dure à mettre à en place.

Je ne suis pas certain que Java Web Start résolve tous ces problèmes pour une application purement Swing/SWT, notamment vu que les RCP tels Netbeans/Eclipse proposent un module de mise à jour.

Si tu utilises un RCP (tel que Netbeans/Eclipse) tu as effectivement un UpdateCenter mis à disposition.

Si tu utilises Swing pur, le moyen le plus rapide est Java Web Start.

Sinon faut écrire son propre outil