GWT est-il du Java ?

Suite à mon post sur la création de bibliothèques GWT-compatible, un débat est lancé :

GWT émule en effet certaines fonctionnalités de Java pour les traduire en Javascript dans l'environnement d'un navigateur web standard, et il faut en permanence songer que l'exécution est en dehors d'une JVM. Importez simplement une bibliothèque quelconque, comme JDOM, et vous aurez des messages d'erreurs en pagaye.

La question est donc lancée : doit-on affirmer qu'un programme client GWT est fait en Java ? Cela n'introduit-il pas trop de confusions, d'espoirs déçus et de temps perdu ?

Personnellement, je dirais qu'un programme client GWT est écrit en JAVA mais n'est pas du Java.
Tout d'abord javascript est mono thread contrairement à Java ce qui peut changer pas mal de chose dans certains cas.

Ensuite, il y a suffisamment de personnes qui ne savent pas si leur code tourne coté client ou serveur (meme du php ou un applet java). Si on commence a dire que c'est du JAVA je crois que ca va embrouiller les gens plus qu'autre chose.

Enfin il n'y a pas certaines fonctions de java tels que les formatter par exemple (doit y'en avoir bien d'autres très utiles mais je n'ai pas été confrontées à celles ci).

Je recopie ici ce que j'avais écrit sur les principales différences GWT/JVM :

• 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
• GWT n'utilise pas de fonctions System : java.util.Locale est incompatible avec GWT car est capable de lire une Locale par défaut dans le System de la JVM
• GWT ne peut évidemment pas lire un fichier : il est donc malheureusement impossible d'utiliser directement les ResourceBundle pour internationaliser son code.
• GWT ne gère pas les 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.
• GWT n'émule pas tout : une fonction assez simple comme Class.getSimpleName() n'est pas émulée. Voici la liste des fonctions émulées.

A mon avis, excepté l'anecdotique getSimpleName(), toutes ces limitations sont bien justifiées, et l'équipe de GWT a fait du bon boulot :ccool:. 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 :mouarf:).

Et il me semble que les navigateurs Safari gèrent maintenant les méthodes Http PUT et DELETE....

au final il y a autant de différences entre le java utilisé par GWT et la JDK, qu'il y a de différences entre le javascript et la JRE

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 ... :D

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 :aie: (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).

:fleche: 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 :mrgreen:). 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").

N'oublions pas le but de GWT, qui est de générer le code javascript. alors à mon avis malgré qu'il est en java, mais il pourra pas faire toutes les fonctionnalités incluses dans la JDK.
Je suis d'accord qu'il est en java mais ce n'est pas du java.

Bonjour

Je suis assez d'accord avec anawak2002. Avec GWT, on écrit du Java, un peu sur le modèle Swing. Avec des limitations de compatibilité avec la JRE 1.5, mais :
- On ne compile pas. C'est un "compiler" Java2Javascript qui transforme le code Java en Javascript.
- GWT n'est qu'un "outil" de création RIA, utilisant le Java comme langage de description des interfaces.

Enfin, c'est ce que je pense après cela que j'ai réalisé pour mon job.

Je pars du principe que si on considère que le langage final n'est pas celui de départ (ici du Java) alors rien n'est du Java. On fait tous de l'assembleur... Ce qui compte quand on dit Java, c'est la compétence dans le domaine, cela veut donc dire qu'une personne codant en GWT fait du Java et sûrement pas autre chose.

Mais ce n'est que mon avis ;)

Ce que tu dis n'est pas faux ! (Par contre, avec ta tournure de phrase, je l'ai bien compris qu'à la deuxième relecture :mrgreen:)

Autre tournure :
Une première embauche faisant du GWT (surtout) client sera t-il capable de développer un projet java en Swing ou en J2EE ?
A t-on besoin d'un expert Java pour être un expert GWT ?

Le terme expert est un peu fort mais j'imagine quand même qu'un développeur ayant fait un peu de Java Swing sera plus à l'aise pour faire des ihm javascript via GWT que s'il devait coder à la main en javascript.

D'ailleurs, c'est ce que disent par exemple ces développeurs.

Cela n'empêche pas que ta question de départ est légitime ;) car si on oublie ce qu'il y a derrière, on comprend pas qu'on ne puisse pas utiliser toutes les librairies java.

Venant du Java Web (J2EE) et non-Web (SWT, Eclipse Platform), cela ne fait qu'une journée que je fais du GWT et je trouve ça extrêmement simple. Je pense que les principes les plus difficiles à prendre en main sont ceux de Module ou non.