Je fais un peu de pub pour un logiciel libre qui gagne a etre connu.
 
NEWS: SwingWT fait partie de Debian, on peut esperer que d'autres distribs suivent.
 
Introduction
 
Tout le monde connait SWT, la librairie graphique libre pour Java cree par IBM et qui est notamment utilise par le projet Eclipse http://eclipse.org/
 
Cette librairie a pour particularite (contrairement a SWING la librairie graphique standard de Java) d'etre native au systeme: par exemple sous Linux, une application SWT est en fait une application gtk. L'avantage principale est la rapidite accrue par rapport a SWING.
Pour en savoir plus sur SWT: http://en.wikipedia.org/wiki/SWT
 
SwingWT: c'est quoi et ca apporte quoi ?
 
SwingWT http://swingwt.sourceforge.net/ est une re-implementation des widgets SWING en SWT. Ceci apporte qu'en programmant en Java/SWING standard, on peut fournir une application dont la partie graphique est native a l'environnement grace a SWT sans changer une ligne de code, juste en "recompilant". voila un screenshot: http://swingwt.sourceforge.net/ss22.png
 
L'etat d'avancement du projet ? SwingWT is into beta now - everything seems to work, it has received some good testing, but some items may be missing (Swing is a BIG API after all). There's probably a few bugs still in there as well
 
SwingWT + GCJ
 
Mais la ou cela devient vraiment interessant c'est de coupler GCJ (partie Java de GCC http://gcc.gnu.org/java/ ) et SwingWT. On obtient alors un programme compile natif (plus besoin de la JVM), bref c'est comme du C/gtk, C++/Qt ou MFC en gros mais avec tous les avantages de Java (temps de developpement diminue).
 
This is Cool GCC: SwingWT + GCJ sous Windows
 
Un developpeur a package SWT, SwingWT et MingW sous windows pour directement pouvoir compiler du code Java/SWING en natif sous Windows. J'ai essaye et ca fonctionne. http://thisiscool.com/gcc_mingw.htm
 
J'ai pu m'amuser (des petites demos) avec et c'est carrement plus rapide que le meme programme version SWING + JVM puisqu'il n'y a pas le temps de chargement de la JVM et SWT reagit beaucoup plus vite que SWING. Le probleme c'est que GCJ ne supporte pas encore toute les classes du JDK1.4, par exemple pour javax.crypto il faudra faire appelle a GNU Crypto et pour javax.net.ssl a Jessie.
 
SWTSwing
 
Un autre projet amusant mais peut etre moins interessant finalement: http://chrriis.brainlex.com/projects/swtswing/
C'est exactement l'inverse de SwingWT, c'est l'implementation de SWT en utilisant les classes de SWING: on obtient un programme SWT aussi portable que le meme ecrit en SWING.
 
Conclusion
 
Bref on va finalement arriver a un Java standard entierement libre et aussi rapide que du C++ grace a GCC, SWT et SwingWT, de la balle non ? On pourra livrer le .jar puis compile en natif le soft sans changer une ligne de code, avoir le meilleur des 2 mondes suivant les besoins.
 
La page SourceForge du projet http://sourceforge.net/projects/swingwt (la page sur SourceForge a ete ouverte en octobre 2003)
 
PS: c'est encore au stade BETA donc a tester sans se plaindre que tout ne fonctionne pas encore.

c'est pas nouveau
mais c'est un chouette projet c'est vrai, pas encore testé

cool

Mais où est passé le plaisir de se farcir le code JFace/SWT à la main?
Stune tragédie pour le programmeur qui aime les belles choses

SwingWT, d'accord ça peut être intéressant, mais compiler en natif franchement non quoi.

mouais, et le système d'UI de swing, il devient quoi ?  
Le modèle Document/View ?
ça s'intègre comment avec les composants lightweight ?

A votre avis c'est possible de faire un L&F swing qui utilise les composants natifs du système ?

 
en passant par JNI ?
 

je vais ptet dire une connerie, mais c'est l'ihm qui utilise du code natif.
 
le code java en amont passe toujours par une machine virtuelle.

plus ou moins, je soupçonne que le l&f de mac os x est fait comme ça. Techniquement, je rame un peu entre composants léger et composants lourds, et cette distinction semble importante pour les choses un peu natives.

 
Pourquoi c'est quoi le probleme ? C'est le meme code source, rien a changer. Sauf que en plus de fournir le .jar comme d'hab tu peux aussi fournir un binaire natif pour Windows ou Linux pour ceux qui veulent. Je pense meme qu'a partir .jar sans le code source tu peux generer le binaire avec GCJ et SwingWT. Et franchement vu la difference au niveau de l'occupation memoire, temps de demarrage, latence de la GUI, integration vis a vis de l'OS ba y'a pas photo. Au niveau developpement ce qui est certain c'est qu'il vaut mieux utiliser la JVM plutot que GCJ car la compilation peut prendre beaucoup de temps.

 
L'IHM (=SwingWT) utilise du code natif (=SWT). Mais on peut coupler SwingWT avec GCJ qui lui est un vrai compilateur Java et produit du code natif comme le fait GCC pour C, C++, Fortran, ADA et Objective-C.
Donc dans ce dernier cas de figure on peut se passe completement de la machine virtuelle.

Ouais enfin j'demande à voir la taille de l'exécutable final

au niveau de tt ce que fait la JVM (inlining, JIT compilation, et surtout la garbage collection) ca donne quoi avec GCJ ?
 
sinon je trouve ca intéressant...mais faut voir ce que la 1.5 va ajouter à swing en terme de rapidité...si ca devient aussi rapide que SWT, y'aura pas besoin de ça...
 
-->après lecture de la TODO, y manque 2-3 trucs encore...mais si le gars s'est tapé tt l'api swing, je dis chapeau

 
Cf http://www.linuxjournal.com/article.php?sid=4860 GCJ semble se comporter pas trop mal. Mais j'ai pu lire aussi des commentaires qui disait souvent que GCJ etait plus lent que la JVM. Remarque il y a souvent des articles pour dire que la JVM est plus rapide que du code C++ compile. Personnellement (et je ne suis pas le seul) a chaque fois que je lance un programme Java je trouve ca lent de maniere generale: GUI, temps de lancement, occupation memoire et c'est justement a ce niveau la que GCJ + SwingWT remet les pendules a l'heure.
 

Ba si il a fait ca ! et les 2-3 trucs qui manquent dans le TODO sont, je pense, des details.

 
L'exemple SwingBrowser.java du CVS de SwingWT donne un .exe de 8Mo avec this-is-cool-gcc en compilant tout en statique. Enfin c'est normal ils peuvent pas faire autrement. C'est comme si les programmes windows etaient compiles statiquement en integrant toutes les dll dont la MFC. Faudrait essayer sous linux puisqu'alors les programmes utiliseraient que des librairies dynamiques .so correspondant a GCJ et autres. Par exemple MINGW (version de GCC pour windows) donnent des binaires beaucoup beaucoup plus gros que GCC sous Unix.

1) c'est un article d'un mec impliqué dedans, donc bon, niveau crédibilité c'est pas top
 
2) tu peux compiler tout ce que tu veux, mais avec un GC aussi pourri que Bohem, c'est pas compliqué de se prendre une taule par VisualWorks 3.5 dès qu'on fait tourner un peu la mémoire.

mais ça l'est déjà, suffit de pas coder comme un goret
(à l'inverse, avec swt, t'es obligé )
 
 
 
 
 

drapal

je vois qd même pas l'intéret de code en natif du java ....code once, run everywhere, ct du vent ???

oui, mais la compilation en natif aussi.

sauf qu'il faut le recompiler pour chaque plateforme si je me goure pas ?

oui, mais de toutes façon il faut packager et intégrer (le tray dans ouinouin, les ApplicationHandler sous OS X etc.) pour chaque plateforme.

ca pourrait etre intelligent que Sun se penche là dessus...
 
parce que dès longhorn, le C# sera plus ou moins natif...