Marwan KHELIF » Java

GWT 2.0 : les nouvelles fonctionnalités

mkhelif — Thu, 14 Jan 2010 12:05:54 +0000

La version 2.0 de GWT (Google Web Toolkit) est sortie (j’ai un peu de retard à cause du boulot ) et avec elle de nombreuses améliorations, principalement pour améliorer le développement des applications. Cette nouvelle version est accompagnée d’un outil d’analyse des performances des sites : Speed Tracer, qui donne des pistes d’amélioration de l’application.

Development Mode

Dans les versions précédentes de GWT, pour tester une application en cours de développement, il y avait le Hosted Mode. C’est une application que l’on lançait depuis son IDE, qui démarrait un serveur Tomcat et qui permettait de tester “rapidement” sont application Web.

En GWT 2.0 le Hosted Mode est remplacé par le In-Browser Development Mode. On installe un plugin (le GWT Developer Plugin) dans son navigateur pour lui permettre de communiquer avec la JVM. Cela permet de bénéficier des différents plugins de son navigateur (Firebug, …) tout en permettant de modifier le code Java en live en rafraichissant la page Web.

UI Binder

Un des problèmes majeurs de GWT dans ses versions précédentes est la gestion de l’interface graphique depuis le code Java. La manipulation des Widgets (composants graphiques dans GWT) depuis le code Java pour leurs appliquer des styles CSS ou gérer des événements finit par donner du code difficile à maintenir.

GWT 2.0 apporte une solution plutôt élégante avec l’UI Binder, ça permet de lier un template XML à une classe Java. Au passage, les fichiers CSS et JavaScripts (librairies externes) référençaient depuis le template sont compressées par le compilateur GWT afin d’en réduire la taille finale.

Ainsi, on sépare l’interface graphique (dans les template .ui.xml) et la logique de l’application dans le code Java.

Code Splitting

Voilà une fonctionnalité attendue par beaucoup de développeurs GWT. Lorsque l’on développe une application GWT, on se rend vite compte que le fichier JavaScript généré prend vite du poids. Cette fonctionnalité découpe l’application en plusieurs fichiers JavaScript qui seront chargés uniquement lorsque c’est nécessaire en rajoutant quelques lignes de codes.

Layout par contraintes

Beaucoup d’applications Web qui se basent sur JavaScript utilisent des widgets qui sont positionnées dans la page grâce à des calculs qui peuvent ralentir l’affichage de l’application.

À l’inverse, GWT 2.0 génère le rendu final en utilisant le CSS de la page, celui-ci est généré à la compilation et non plus pendant l’affichage de la page ce qui réduit considérablement le temps de chargement.

ClientBundle

Je présentais dans mon billet : Guide d’optimisation de vos applications Web une méthode pour réduire le temps de chargement d’une page en utilisant des images sprites.

GWT est capable depuis la version 1.4 de faire tout cela automatiquement grâce aux ImageBundle. Toutes les images référencées sur disque étaient réunies en une seule est GWT utilisé la technique des sprites pour afficher les images convenablement. Avec GWT 1.5/1.6, un projet de l’incubateur permettait de faire la même chose avec à peu près n’importe quels fichiers.

GWT 2.0 introduit cette notion avec les ClientBundle. Par exemple, vous pouvez références tous vos fichiers CSS, GWT va alors les regrouper en un seul fichier, le minimiser et le rendre disponible pour être mis en cache. GWT gère aussi l’internationalisation ainsi vous pouvez gérer vos ClientBundle pour chaque locale.

Speed Tracer

Cette nouvelle version sort avec une extension pour Google Chrome : Speed Tracer. Cette extension analyse l’exécution de l’application Web en cours. Plutôt que de longues explications, voilà la vidéo de présentation de Speed Tracer.

Présentation de Speed Tracer

Story of Your Compile

SOYC fournit de nombreux détails sur la compilation de chaque partie de l’application GWT : la taille, les dépendances, temps de compilation… Cela permet d’orienter ses efforts pour diviser le code grâce Code Splitting

Traces dans IE 6

Internet Explorer ne fournit pas les traces lorsqu’une exception JavaScript est levée, ce qui peut être très embêtant lors d’une phase de debug sur ce navigateur…

Avec GWT 2.0 vous obtenez maintenant la trace obfusquée (ou non en fonction de la compilation choisie) JavaScript qui peut être convertie en trace Java avec nom de classe et numéro de ligne.

Conclusion

Ce billet ne présente que les améliorations les plus importantes, mais il y à de très nombreuses évolutions : optimisation du compilateur, évaluation directe des réponses RPC (réduction du temps de déserialisation), propriété de deffered binding conditionnelles, …

GWT devient de plus en plus un framework “productif” : la plupart des problèmes qu’un développeur rencontre lors du développement d’une application Web qui utilise JavaScript, sont résolus très simplement.

Pensez-vous que cette version 2.0 de GWT va permettre au framework de gagner des parts de marché face à ses concurrents comme Flex?

Pour suivre votre lecture

Ruby on Rails : déployer une application sur Tomcat avec JRuby

mkhelif — Mon, 07 Sep 2009 15:46:18 +0000

Ruby on Rails est un framework qui permet de développer très rapidement des applications Web en suivant le modèle MVC.

Le problème de ce framework est qu’il se base sur le langage Ruby et qu’il embarque un serveur Web. Les applications ainsi créées ne peuvent pas être déployées comme des applications Web dans Tomcat ou autres serveurs d’applications.

Le but de ce tutoriel est de vous permettre de déployer les applications Ruby on Rails (RoR) sur un serveur Tomcat en utilisant la librairie JRuby.

Installation Tomcat

On commence par télécharger la dernière version de Tomcat (en ce moment c’est la version 6.0.20) :

1 2	wget http://mirror.mkhelif.fr/apache/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.tar.gz tar –xzf apache-tomcat-6.0.20.tar.gz

Voilà Tomcat est installé, je passerai ici la configuration du serveur. Si vous souhaitez, suivez mon tutoriel pour connecter Apache avec Tomcat.

Installation JRuby

Télécharger JRuby et placez le là où vous souhaitez :

1
2
3

wget http://dist.codehaus.org/jruby/1.3.1/jruby-bin-1.3.1.tar.gz
tar –xzf jruby-bin-1.3.1.tar.gz
mv jruby-1.3.1 /usr/local/jruby

Ajouter ensuite le chemin vers JRuby dans votre environnement en éditant votre fichier ~/.profile :

1	export PATH=$PATH:/usr/local/jruby/bin

Vous pouvez vérifier l’installation de JRuby en exécutant la commande suivante :

1 2	$ jruby -v jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM) Client VM 1.5.0_16) [i386-java]

Installation de Ruby on Rails

À partir de là nous allons installer les gems pour : rails (le coeur de ROR), mysql et surtout warbler (qui crée un WAR à partir de l’application rails).

1
2
3

$ jruby -S gem install rails
$ jruby -S gem install activerecord-jdbcmysql-adapter
$ jruby -S gem install warbler

Déploiement de votre application

Pour déployer votre application dans Tomcat, il faut commencer par la convertir en WAR. Placez vous dans le dossier de votre application et lancez la commande suivante :

1	$ warble config

Cela va créer un fichier /config/warble.rb pour configurer votre application pour la convertir en fichier WAR, ouvrez le fichier et dé-commentez la ligne :

1	config.gems += ["activerecord-jdbcmysql-adapter"]

Cela pour inclure dans votre fichiers WAR la gem MySQL (ajoutez les gems que votre application utilise ici).

Maintenant nous allons créer le fichier WAR de votre application, lancez simplement la commande :

$ warble

Et voilà votre fichier WAR est créé, vous pouvez alors le déployer sur Tomcat (je passerai sur cette étape).

Pour suivre votre lecture

Ouverture du Java Store

mkhelif — Wed, 03 Jun 2009 12:30:18 +0000

Sun vient de lancer un AppStore pour les applications Java et JavaFX : le Java Store (ils sont pas allé chercher très loin pour le nom). Pour l’instant disponible uniquement en béta privé, la version finale devrait être disponible d’ici à la fin de l’année.

Actuellement deux applications sont présentes : RuneScape et TwitterFX (client JavaFX pour Twitter). Les applications sont “entreposées” dans le Java Warehouse, pour l’instant gratuit (uniquement ouvert aux États-Unis) il faudra ensuite payer un abonnement annuel pour pouvoir déployer ses applications.

Compte tenu du nombre d’ordinateurs qui ont une JRE installés, c’est un bon moyen pour les développeurs indépendants pour vendre leurs applications.

Pour suivre votre lecture

Oracle rachète Sun

mkhelif — Mon, 20 Apr 2009 13:09:55 +0000

IBM vient de se faire couper l’herbe sous le pied par Oracle pour le rachat de Sun. En ce moment (depuis 5:30am Pacifique) une conférence est en cours pour discuter de la transaction.

Cette transaction s’élève donc à 7,4 milliard de dollars, soit 9,5 dollars par action. Pour rappel, IBM avait proposé environ 7 milliards de dollars.

Pour Oracle ce rachat permet d’assurer le développement de Java sur lesquels sont basés la suite Oracle Fusion Middleware. La suite est actuellement le produit qui amène le plus de business à Oracle.

D’autre part, Solaris, est le plus utilisé comme système d’exploitation du serveur de base de données Oracle.

Source : http://www.sun.com/aboutsun/pr/2009-04/sunflash.20090420.1.xml

Pour suivre votre lecture

Première utilisation du plugin Eclipse GWT

mkhelif — Fri, 10 Apr 2009 15:30:35 +0000

Suite à mon premier billet qui présentait Google Web Toolkit, je vais maintenant vous présenter la nouvelle version de GWT et comment créer un premier projet en utilisant le plugin Eclipse.

Mise en place de l’environnement de développement

Pour commencer à développer une application GWT et/ou GAE (Google App Engine), il faut télécharger la dernière version de Eclipse.

Une fois Eclipse installé et démarré, il faut installer le plugin GWT/GAE de Google. Pour cela allez dans le menu « Help / Software updates…« . Allez dans l’onglet « Available Software » et ajouter un nouveau site ( »Add site… ») et entrez l’URL : http://dl.google.com/eclipse/plugin/3.4.

Sélectionnez alors les éléments Plugin et SDKs, puis cliquez sur « Install« . Une fois l’installation terminée, vous devez redémarrer Eclipse. Là une nouvelle barre d’outils est apparue :

Le premier bouton sert à créer une nouvelle application Web GWT/GAE, le second à compiler une projet GWT et le troisième à déployer une application GAE dans le cloud Google.

Voilà votre environnement de développement est prêt à être utiliser.

Création de mon premier projet

Pour créer un nouveau projet cliquez sur le bouton . Cela va démarrer l’assistant de création de projet :

Les principaux champs à renseigner sont le nom du projet : GWTDemo, et le package racine de l’application : fr.mkhelif.gwt.demo. Pour l’exemple je n’ai sélectionné que GWT, je ferais un autre billet sur GAE.

Structure du projet

Une fois le projet créé, voilà la structure que l’on obtient :

On voit donc un nouveau dossier war, c’est celui-ci qui représente l’archive WAR qui sera exportée/déployée. Lors de la compilation du projet, les fichiers seront créés dans un sous-dossier de celui-là. Le répertoire lib du WEB-INF contient la librairie nécessaire au fonctionnement des service GWT-RPC sur le serveur.

On peut voir que le dossier public du package par défaut à disparu. Maintenant, toutes les ressources (images, css, …) doivent être placées dans le répertoire war à l’instar d’une application Web classique.

Notre nouveau projet contient par défaut deux fichiers : GWTDemo.html et GWTDemo.css. Le fichier HTML sert à charger l’application GWT et le fichier css représente le style de l’application.

Au niveau du répertoire de sources src, on retrouve les packages client et server, et le fichier GWTDemo.gwt.xml. Au niveau de ce fichier, il n’y a pas de changements notables.

Le nouveau projet contient un exemple de service RPC : GreetingService. Voilà le code de l’interface du service :

package fr.mkhelif.gwt.demo.client;
 
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
 
/**
 * The client side stub for the RPC service.
 */
@RemoteServiceRelativePath("greet")
public interface GreetingService extends RemoteService {
    String greetServer(String name);
}

On remarque que l’interface étend toujours RemoteService, par contre une nouvelle annotation est présente : @RemoveServiceRelativePath( »greet »). Cette annotation permet de s’affranchir au niveau du code client d’enregistrer l’URL de la servlet du service :

1	((ServiceDefTarget) service).setServiceEntryPoint (GWT.getModuleBaseURL () + "greet");

Par contre il n’y a aucune différence au niveau de son implémentation et de son clone asynchrone.

Compilation du projet

Voilà le projet est créé, il faut maintenant le compiler en cliquant sur le bouton . Le wizard suivant apparait :

Il suffit de sélectionner le projet GWT, le niveau de log du compilateur et le style de sortie du JavaScript compilé. Sélectionnez ensuite les points d’entrées de votre application GWT, dans notre exemple il n’y en a qu’un.

On peut remarquer que grâce au plugin on peut spécifier des arguments de compilation. Le paramètre localWorkers permet de définir le nombre de workers utilisés pour compiler les permutations JavaScript. D’autres options sont disponibles mais ne concerne que les dossiers de compilation : workDir, war et extra.

Ayant un dual-core, je demande au compilateur d’utiliser 2 workers pour compiler. Le gain de temps est d’environ 30% : 28 secondes sans l’option et 19 secondes avec.

Utilisation de l’application

Une fois l’application GWT compilée, il faut la tester grâce au hosted mode. Il n’y a pas de grande différence au niveau du hosted mode, sauf que maintenant il est possible de modifier le serveur utilisé par GWT pour démarrer l’application.

On remarque un nouveau bouton Restart Server dans la fenêtre du hosted mode. Ce bouton permet de redémarrer le serveur, et donc de redéployer le WAR, sans avoir à relancer le hosted mode.

Conclusion

C’est un très beau coup de pub qu’à fait Google en nous servant en même temps le support de Java par Google App Engine, la version 1.6 de GWT et un plugin Eclipse pour gérer très facilement le tout. Cela va donner un coup de boost aux développeurs qui étaient encore hésitant sur la fiabilité de GWT.

Pour suivre votre lecture

Google : GWT version 1.6 et consorts

mkhelif — Wed, 08 Apr 2009 08:55:12 +0000

Ça y est, la version 1.6 officielle de GWT est enfin disponible après deux releases candidates (RC). Les nouveautés annoncées sont bien présentes. Parmi les nouveautés les plus importantes :

Une refonte de l’architecture d’une application GWT pour qu’elle corresponde à celle d’un WAR. Cette nouvelle architecture est plus intuitive pour développer une application complète (testée avec le plugin Eclipse Cypal Studio).
Une parallélisation du compilateur permet sur une machine multi-coeurs de diminuer sensiblement la durée de compilation. Maintenant, la compilation peut aussi être distribuée entre plusieurs machines.
Une nouvelle approche de la gestion de événements par Handler. Pour avoir testé cette nouvelle implémentation, on se rapproche beaucoup plus de la gestion des événements Swing.

En marge de GWT, Google App Engine, la plateforme de déploiement des applications Web de Google, accepte désormais les applications Java dans un environnement Java 6. Cet environnement comprend les API suivantes : Java Data Objects (JDO), Java Persistence API (JPA) et JavaMail API.

Par ailleurs, Google a aussi développé un plugin Eclipse pour les développeurs GWT et Google App Engine. Ce plugin contient :

Un assistant de création d’applications Web spécifique pour GWT ou Google App Engine.
Un assistant de déploiement de votre application dans le cloud de Google.
Une coloration syntaxique de votre code JSNI (JavaScript Native Interface). Très utile, surtout lorsqu’on à pris l’habitude de coder avec une coloration de commentaire…

Divers autres fonctionnalités sont disponibles avec ce plugin, mais je ne les ai pas encore testé.

Source : Introducing GWT 1.6 and friends.

Pour suivre votre lecture

Java : JFrame transparente

mkhelif — Fri, 23 Jan 2009 16:08:14 +0000

La prochaine version du JDK (1.6.0_12) va permettre de réaliser en Java des fenêtres transparentes ainsi que de modifier la forme de ces dernières. Tout ceci grâce à la classe (privée certes) : com.sun.awt.AWTUtilities.

Pour avoir accès à cette classe vous devez télécharger la version en question : JDK 1.6.0_12 b3.

Les méthodes pour modifier les fenêtres Java sont :

AWTUtilities.setWindowShape (window, shape);
AWTUtilities.setWindowOpacity (window, opacity);

Voici quelques exemples de ce que permet de faire cette classe :

JFrame standard

JFrame avec opacité à 0.8 (entre 0 et 1)

JFrame dont la forme est modifiée

JFrame avec une forme est une opacité modifiée

Pour suivre votre lecture

GWT 1.6 : quoi de neuf ?

mkhelif — Thu, 11 Dec 2008 10:44:04 +0000

Ça y est la roadmap pour la version 1.6 de GWT a été publiée sur le blog officiel de GWT. Aucune date précise quand à la sortie de cette version, mais elle est annoncée pour le premier trimestre 2009.

Voilà les nouvelles fonctionnalités pour cette version :

Nouvelle structure de déploiement : l’objectif étant de permettre un déploiement plus simple des WARs sur un serveur d’applications. Il s’agit surtout d’une restructuration dont voici la spécification.
Jetty sera utilisé à la place de Tomcat (j’en parlais d’en un billet précédent). Une architecture plus modulable du hosted mode permettra de changer le serveur utilisé.
Uniformisation des événements : les listeners actuels seront dépréciés et les nouveaux seront uniformisés pour tous les widgets.
Intégration du DatePicker et du LazyPanel depuis l’incubateur GWT. Le DatePicker est comme son nom l’indique un widget permettant de sélectionner des dates (démo du DatePicker). Le LazyPanel permet de charger un composant uniquement lorsqu’on en a besoin (appel à la méthode setVisible (true)), ça permet de gagner du temps lors de l’initialisation de l’application.
Optimisation des String : les StringBuilder seront optimisés pour chaque navigateurs grâce au deferred binding (optimisation à la compilation).
Optimisation du compilateur GWT : réduction du temps de compilation.

Et celles qui sont prévues pour la suite :

Découpage du code JavaScript généré en plusieurs fichiers. Le développeur pourra spécifier des points de césures qui permettront au compilateur de découper le code généré en plusieurs fichiers. Cela permettra évidemment d’éviter au client de télécharger toute l’application GWT en un seul fichier. Ceci lié au LazyPanel, les applications GWT devraient gagner en rapidité de chargement.
Analyse du code compilé, appelée Story Of Your Compile (SOYC) : rapport permettant aux développeurs de savoir quelle classe génère le plus de code JavaScript.
Sélection du navigateur à utiliser pour le hosted mode.
Ui Binder : création des composants par déclaration, permet de séparer le layouting des composants (géré dans un fichier XML) de leur lien avec le modèle (géré dans le code Java).
Client Bundle : généralisation du deferred binding (utilisé actuellement dans les Image Bundle) aux autres ressources statiques (css : CSSRessource, texte : TextRessource, image : ImageRessource).
Optimisation du protocole RPC.

EDIT: La version 1.6 de GWT est sortie.

Pour suivre votre lecture

GWT : le futur hosted mode

mkhelif — Tue, 09 Dec 2008 09:42:05 +0000

Architecture : Out Of Process Hosted Mode (OOPHM)

La future version 2.0 de GWT nous annonce une grande amélioration du hosted mode. Pour rappel le hosted mode permet aux développeurs d’application GWT de pouvoir débugger leur code dans un navigateur embarqué sans avoir à passer par la compilation du Java en JavaScript.

La version actuelle du hosted mode ne permet pas de sélectionner le navigateur à utiliser (par défaut : IE sur Windows, Mozilla sur Linux et WebKit sur Mac). Cette nouvelle mouture permettra donc, à l’aide de plugins, de s’intégrer dans « tous » les navigateurs.

Ces plugins communiqueront par TCP avec la JVM de GWT et comme maintenant le code JavaScript ne sera pas généré ce qui permettra de débugger le code Java.

Source : DNG Consulting (regardez la vidéo ça donne envie).

Pour suivre votre lecture

GWT 1.6 : Tomcat ou Jetty ?

mkhelif — Tue, 21 Oct 2008 13:17:52 +0000

Après la sortie de la version 1.5 de GWT, la roadmap de GWT 1.6 est en cours de préparation. Bruce Johnson, développeur en chef du projet GWT, demande à la communauté de développeurs de donner son avis sur le choix du prochain serveur du hosted mode : Tomcat (serveur actuel) ou Jetty.

Ayant plus travaillé avec Tomcat que Jetty je suis favorable au maintien du serveur actuel. Je reconnais cependant que Jetty est beaucoup plus rapide que Tomcat.

Si vous souhaitez participer au débat en donnant votre avis : http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/604aec6b7460c133?hl=en&pli=1

Et vous qu’en pensez vous?