Swing et plate-forme RCP (1ère partie)

(deuxième partie)

J’avais un conflit d’agenda
le 13
octobre 2006 entre un engagement impératif et
l’événement
Eclipse Now You Can (même si, bien entendu, je reste
persuadé
des avantages techniques et stratégiques d’une solution
à
base de Swing et de NetBeans
Platform
). Les planches des présentations de cet
événement
Eclipse étant maintenant disponibles,
je les ai passé rapidement en revue.

Je connaissais
déjà la
présentation de Didier Girard (au nom de son employeur
près
;-) sauf pour les exemples en fin de présentations. Je ne
suis
toujours pas convaincu par les problèmes potentiels des
mashups coté serveur (Didier, je pense que la
fédération
comme celle de Liberty Alliance est une excellente réponse
à
ce problème d’identité numérique qui
ne date pas
des mashups). Je ne vois pas non plus vraiment de coté
bureau
d’entreprise dans les exemples proposés.

Une application
d’entreprise (de
gestion) c’est nécessairement des dizaines voire des
centaines
d’écrans (à tel point que
« l’écran »
est souvent un indice de productivité: combien de jours pour
modifier cet écran?). Du coup, la présentation
« Objectif Eclipse RCP »
d’Improve Mana et de
(du?) Vidal devient particulièrement
intéressante.

Les quatre
premières difficultés
(java, ergonomie, plugins, organisation du code) sont
inhérentes
à tout RCP je pense. La cinquième est beaucoup
plus
intéressante:

Difficulté
5 : l’API de composants graphiques
SWT/JFace a des
lacunes
Trop de code à
produire
Trop confus
Manque de
composants adaptés à l’informatique de
gestion

Le plus gros
problème d’Eclipse
RCP à court et à moyen terme c’est SWT et y
rajouter la
sur-couche JFace n’y change pas grand chose. A l’heure du Web 2.0,
les copies d’écran de Didier Girard apparaissent un peu
fades
et l’absence de marché SWT et la difficulté de
spécialiser les composants SWT n’y sont pas
étrangés.

Coté Swing (la
technologie
utilisée dans NetBeans Platform) on a maintenant Matisse
qui ne fini pas de surprendre. J’ai repris la planche 20 de la
présentation
sur la migration de VB à Eclipse RCP
qui parle de
100
lignes de code en VB contre 400 en SWT/JFace. Avec Matisse, cela fait
145 lignes, mais toutes sont générées
après
20 minutes d’utilisation de NetBeans. C’est un peu plus de lignes
qu’avec VB, mais on passe en java et on devient portable :

Si on ne
considère que le code
de mise en page (layout), on passe à 99 lignes ! La
comparaison reste difficile sans regarder plus en détail ce
qu’il y a derrière les 100 lignes VB et les 400 lignes SWT.

Ce qui devient encore plus
intéressant,
c’est Swing
Application
Framework
(JSR 296) et Beans
Binding
(JSR 295) qui, à mon avis, corrigent au
moins en
partie les quatre premiers points
énumérés
ci-dessus si la problématique ne nécessite pas
réellement un véritable RCP.

Dans tous les cas, un
framework comme
MONOI me rappelle furieusement les nombreux frameworks
dérivés
de STRUTS que j’ai pu rencontrer chez des clients et des partenaires
intégrateurs. Tous étaient pertinants, mais rares
sont
ceux qui étaient suffisamment évolutifs pour
permettre
un passage à JSF. D’ailleurs, pourquoi MONOI n’utilise-t-il
pas le binding
proposé par Eclipse
?

Les outils joueront un
rôle
majeur dès que les JSR 295 et JSR 296 seront sortis. Eclipse
restera-t-il dans son coin avec ses technologies propres?

Quelques liens
complémentaires
sur ces sujets:
A
Framework for Swing – An Interview with Hans Muller
How
I moved my Swing application to the NetBeans Platform
NetBeans
Platform : Leveraging the Swing Ecosystem, Network App Management and
Tons of Components and Services

(deuxième partie)

Author: alexismp

Google Developer Relations in Paris.

3 thoughts on “Swing et plate-forme RCP (1ère partie)”

  1. Pour information, nous avons aussi codé l’écran en Swing et le constat est le même qu’avec SWT (400 lignes de code). Mais il est vrai que nous n’avons pas utilisé Matisse.
    Le framework Monoi peut facilement être critiqué puisqu’il n’a que 2 semaines d’existence mais il a le mérite d’être guidé par les besoins concrets et immédiats. Aujourd’hui, je ne connais pas d’équivalent (en terme de clarté du code et de productivité), que ce soit sur SWT ou sur Swing d’ailleurs.
    Je suis ravi d’entendre parler de ces JSR mais après 8 ans d’existence de Swing, en être encore à ce stade, n’est-ce pas un peu navrant ?
    Enfin, personnellement, je préfère nettement Swing à SWT, mais dans mon métier, c’est le marché qui décide… Ceci dit, j’ai toujours espoir de retravailler sur Swing à l’avenir !

  2. en être encore à ce stade, n’est-ce pas un peu navrant ?
    Vieux motard….

    Mon but n’est pas de critiquer Monoi (je n’y ai pas touché). Simplement la tâche est plus difficile avec ces JSR qui arrivent.

Comments are closed.