août
2009
Un article de nicorama
GWT émule en effet certaines fonctionnalités de Java pour les traduire en Javascript dans l’environnement d’un navigateur web standard.
Importez simplement une bibliothèque quelconque, comme JDOM, et vous aurez des messages d’erreurs en pagaye. Seule des bibliothèques spécialement conçues pourront être utilisées à la fois en GWT client et dans n’importe quelle JVM.
A chaque fois que vous écrivez du code Java fonctionnant à la fois côté serveur et client, il faut garder en tête de :
– GWT utilise directement les composants du navigateur : il utilise le DOM interne, ainsi que l’objet XmlHttpRequest- et donc ne connait ni Sax, ni JDOM, si le java.net.HttpClient
– Ne pas utiliser de fonctions System : il n’y a pas de compatibilité entre la JVM et le moteur du navigateur. java.util.Locale est incompatible avec GWT car est capable de lire une Locale par défaut dans le System de la JVM
– Ne pas lire un fichier : il est très malheureusement impossible d’utiliser les ResourceBundle pour internationaliser son code.
– Ne pas se mêler des Charset : le fonctionnement est trop différent entre la JVM et le navigateur. Je ne suis pas spécialiste, mais concrètement, les fonctions de type public byte[] getBytes(« UTF-8″) ne fonctionneront pas. Cela rend les fonctions de types MD5 et base64 sont pour l’instant incompatibles.
– Vérifier la liste des fonctions émulées : une fonction assez simple comme Class.getSimpleName() n’est pas émulée.
Alors est-il possible d’écrire une bibliothèque Java utilisable – et utile – côté client et serveur ? Oui, vous y arriverez en y passant suffisamment de temps et à la simple condition de maîtriser le concept de l’interface. Vous pouvez aussi attendre Octobre et la sortie de Robusta Web Library qui vous facilitera grandement la tâche.
Suite de la discussion dans le forum :
http://www.developpez.net/forums/d795559/java/developpement-web-java/frameworks/gwt/gwt-java/
C’est le cas depuis ce matin
– Pour downloader et surtout la doc, il va falloir attendre encore un peu.
Quand je parle de bibliothèque business, je parle des classes contenant la logique métier qu’une application va utiliser. Pour moi, il s’agit des classes Teacher, School, Course, Hemisphere, etc… J’en connais donc deux GWT-compatibles : Robusta et Edupassion.
Je rajouterais même, pour faire ma pub, qu’utiliser Robusta simplifie pas mal la « GWT-comptabilité » de la bibliothèque business.
Le plus dur à rendre compatible est l’internationalisation en utilisant les fichier Properties. Un sacré casse-tête, surtout avec plusieurs fichiers bundle.
La presse peut parfois exagérer (effet d’annonces). Ceci dit, considérons la phrase « La promesse de GWT est d’utiliser Java côté client et serveur ».
Elle peut paraître exacte ou non suivant la sémantique que l’on attribue au mot Java.
Si par Java, on entend comme moi « la syntaxe », elle se relève plutôt juste.
Maintenant, si on entend par Java « les librairies », il est évident qu’elle est fausse.
Java, c’est à la fois une marque, un langage (syntaxe), un environnement (librairies / outils) … bref, ça recouvre beaucoup de sens (polysémie).
Les bibliothèques « business » qui « fonctionne » des deux côtés, tu en connait beaucoup ?
Il y a des librairies GWT (côté client), des librairies Java (côté serveur), des librairies à cheval des deux côtés mais une librairie qui fonctionnerait à la fois côté serveur (Java) et à la fois côté client (Javascript), ça doit être quand même assez réduit, non ?
Robusta fonctionnera des deux côtés ? ;o)
La promesse, dans la presse, de GWT est d’utiliser Java côté client et serveur – et on comprend bien souvent pouvoir utiliser le même code.
Sur le site de GWT, c’est beaucoup plus adoucit, on ne peut pas le leur reprocher. De plus il est quand même possible – bien que délicat – d’utiliser ses bibliothèques Business de part et d’autres, et là, c’est un must.
Le problème de GWT, c’est comme on écrit du Java, on peut avoir tendance à oublier les limites …
Pour ma part, je me dis que je code du html/js (mais j’écris du code Java à la place) et là, il n’y a plus de risque ! Et au contraire, je me dis parfois que si je devais écrire un truc équivalent en javascript, ça sera beaucoup plus embêtant …
C’est sûr que pour la Locale et le getSimpleName, ils ont pas assurés !