Le mot Java recouvre beaucoup de choses :
- un langage (avec sa syntaxe, son typage, ...)
- un compilateur qui transforme le source en byte code
- une machine virtuelle qui exécute le byte code
- un écosystème avec ses outils et ses librairies, ...
- une marque ...
Je crois qu'il serait salutaire de garder à l'esprit que
GWT permet d'écrire un code Javascript avec une syntaxe à la Java qui s'exécute dans un navigateur. Pour preuve, si on écrit une application sans partie serveur, au final, pas besoin de JVM, juste du js/css/html.
Cela évite ainsi de vouloir tout faire dans un client web ...
Toutes les librairies JAVA sont adaptés à un domaine et il y a donc des limites. Personne n'essayera d'utiliser un bouton GWT ou un bouton SWT dans une application Swing
(enfin, j'espère)
Le problème le plus sournois (et rien qu'à lire ce forum, il en a troublé plus d'un) c'est leur émulation partielle du JDK (avec les mêmes noms de classes)
Si d'autres noms avaient été utilisés, cela aurait été moins perturbant d'un côté mais plus d'un autre. C'est le cas par exemple du framework WebObject qui a ses NSArray (List), ses NSDictionnary (Hashtable) et c'est lourd.
En revanche, on mettra à leur crédit la création par défaut d'une
partie cliente (le code JAVAscript *) et d'une
partie serveur (le code full JAVA).
- Le code JAVAscript côté client doit être du code "GWTCompatible", c'est à dire doit faire référence à du code lui même GWTCompatible (des librairies GWT, les classes du toolkit et leur émulation partielle du JDK)
- Le code JAVA côté serveur (dossier serveur par défaut) peut faire référence à toutes les librairies JAVA que l'on souhaite.
Une fois ceci en tête, il n'y a pas de souci mais je t'accorde que l'on peut vite être perdu si on ne structure pas son code :
- ici, c'est ce qui sera exécuté dans le navigateur (donc en js)
- là, c'est ce qui sera exécuté sur le serveur (donc en java)
...
Et la structuration du code, c'est ce qui manque à ceux qui ne sont par architecte dans l'âme.
Rappelons que
GWT est un toolkit (boite à outils) et pas un framework (qui est un cadre de travail).
Pour répondre à ta question : GWT est-il du Java ?Posée ainsi, la question est délicate.
Elle revient à se demander : Est-ce que cette boite à outils appelée GWT est elle du Java ?
Sachant qu'il peut être généré à partir d'autres langages, est-ce qu'un byte code de JVM est du Java ?
Pour faire moi aussi une analogie, je dirai que le JAVA de GWT est à V8 (et autre moteur javascript) ce que Groovy, Scala, JPython, ... sont à la JVM (autre syntaxe mais même runtime)
Avec GWT, Javascript devient comparable à du byte code. C'est le résultat d'une compilation d'un code source Java en un langage interprété par une machine virtuelle (Moteur Javascript dans un cas, JVM dans l'autre).
Si tu juges un code appartenir à un langage X vis à vis de ses pairs (autre code (librairie) en langage X) alors :
- Si tu compares le code source Java de ta partie cliente GWT à d'autre code sources de librairies Java, il te semblera compatible (ça ressemble à du café, ça a le gôut du café, ... mais des fois, il est amer
). La réponse est donc un petit oui. - Si tu compares le code résultant de la compilation de ta partie cliente GWT à d'autre code résultant de la compilation de librairies Java, il sera parfois compatible (librairies JAVAscript "GWT compatible" écrites en Java et compilée par GWT) et parfois pas (bytecode de librairies Java compilée par Javac). La réponse est donc un petit non.
* par JAVAscript, j'entends code JAVA qui sera traduit en javascript (code que je nomme par ailleurs code Java "GWT Compatible"
.
0 |
0 |
. On frôlerai le génie si les Charset communs étaient gérés, si l'internationalisation était moins contraignante et si XMLParser connaissait XPath (et si possible dans les deux semaines, j'ai un job à finir 
).