florentgarin.org

JavaOne s'est déroulé au début du mois à San Francisco. Cette conférence a mis à l'honneur Glassfish, le serveur d'application JavaEE Open Source de Sun, avec le lancement du GlassFish Technology Partner Program dont nous faisons partie. Ce partenariat matérialise notre expertise de la plateforme Java en général et de Glassfish en particulier.
L'autre technologie majeure présentée à JavaOne fut JavaFX. Beaucoup pensent que JavaFX arrive trop tard et qu'il ne pourra pas trouver sa place face à des concurrents comme Flash notamment. Pour ma part, je suis convaincu du contraire.
Le succès de Flash est éclatant et cela est largement justifié : très grande facilité de déploiement, temps de démarrage à froid impressionnant, qualité des outils de production, des codecs vidéo...
Néanmoins, dans le cadre du développement d'une application d'entreprise disposer d'un langage aussi riche que Java sur le client, surtout s'il est aussi utilisé sur le serveur, est un énorme avantage. Si JavaFX continue de progresser et que la version finale de Java SE 6 Update 10 tient toutes ses promesses, je recommanderai JavaFX et non Flex à nos clients industriels.

Voilà un certain temps que Thomas m'a filé une invitation pour essayer Goojet et que je m'étais dit qu'il fallait que je poste sur le sujet.

Goojet est, avant tout, une application pour téléphone portable. Son ambition est de devenir le portail de votre mobile. L'innovation de Goojet tient à son approche hybride : web/téléphone. Vous pouvez en effet utiliser Goojet depuis votre ordinateur puis synchroniser l'état de l'application sur votre mobile.
Au delà de sa levée de fond, la force de Goojet réside dans la qualité de son équipe. Projet à suivre assurément, en plus c'est une startup Toulousaine !

JSF ne s'est pas encore, gardons espoir, véritablement imposé comme LE framework web java.
La première des raisons est sans doute sa complexité. Essayez d'expliquer à un féru de php son Unified Expression Language pour vous en convaincre.
Deuxièmement, la spécification de JSF ne définit qu'une palette de composants graphiques très limité. Dans un projet réel, ceux-ci suffisent rarement ; il faut alors se tourner vers des extensions propriétaires, perdant du même coup la neutralité vis à vis de l'implémentation de JSF.
Enfin, le dernier point problématique est la difficulté d'intégration de JSF et d'AJAX.
Il est en effet compliqué de mixer l'approche purement "server-side" de JSF avec une logique AJAX où une partie du MVC est directement implémentée sur le client en javascript.
La jsr 314, celle de JSF 2.0, devrait remédier à cela en apportant des modifications importantes au cycle de vie notamment le parcours partiel de l'arbre des widgets.
Cela va dans le bon sens, néanmoins, il n'en demeurera pas moins que de plus en plus la logique cliente se trouvera portée par du code AJAX, laissant à JSF la gestion des tâches annexes.
Si JSF 2 marquera indéniablement l'acceptation d'AJAX par Java EE, ne faudrait-il cependant pas aller plus loin, en d'autre terme ; pour préserver sa pertinence, JSF 3 ne devra t-il pas être un framework en bonne partie javascript ?

Comment faire pour "uploader" et "downloader" un fichier vers et depuis un web service ?
Très simple me diriez-vous et depuis longtemps. Il suffit d'utiliser SAAJ (SOAP with Attachments API for Java) ou encore mieux MTOM (Message Transmission Optimization Mechanism) pour bénéficier de l'assurance d'une compatibilité .Net/Java optimale.
En théorie cela semble simple mais quand on passe à la pratique, dans le contexte d'une application réelle, les choses se compliquent bigrement, en tout cas en ce qui concerne l'implémentation de JAXWS.
La plus grosse lacune de JAXWS au niveau MTOM est son incapacité à transmettre les données binaires sous forme de flux de bout en bout. Comme expliqué ici il est bien possible d'indiquer au client d'utiliser le mode "streaming" mais côté serveur rien à faire, l'ensemble des octets constituant le fichier est monté en mémoire.
Même côté client, JAXWS mériterait quelques améliorations. En effet il n'est pas possible de superviser la progression du transfert, de plus le mode "streaming" opère en appelant HttpURLConnection.setChunkedStreamingMode sur la connexion sous-jacente ce qui pose des problèmes car de nombreux serveurs web ou proxy ne supportent pas ce mode. Il serait intéressant que JAXWS calcule la taille du contenu à poster et invoque plutôt la méthode HttpURLConnection.setFixedLengthStreamingMode.

Conclusion de tout cela, pour uploader un fichier en http rien ne vaut d'utiliser directement HttpURLConnection et d'implémenter le basique et standard upload multipart/form-data.

Le choix d'inclure (précipitamment ?) JAXB au jdk 1.6 a des conséquences fâcheuses. En effet, la version de l'API intégrée au jdk est la 2.0, et très souvent il est indispensable de passer à la 2.1 pour bénéficier de fonctionnalités comme par exemple l'annotation XmlSeeAlso.
Pas de problème me diriez-vous, il suffit de rajouter -Djava.endorsed.dirs=jaxb-api.jar à la ligne de commande de java pour "patcher" le jdk.
Malheureusement, si votre application est distribuée au travers de Java Web Start, le mécanisme de classes "endorsed" ne fonctionne pas.
Pour s'en sortir une seule solution faire des acrobaties avec les ClassLoaders. Ce billet explique cela en détail. Dans le cadre d'une application swing, il faudra bien penser à appeler la méthode setContextClassLoader également sur le thread gérant les événements système comme ceci :

EventQueue eq = Toolkit.getDefaultToolkit().getSystemEventQueue();
eq.invokeAndWait(new Runnable() {
public void run() {
Thread.currentThread().setContextClassLoader(modifiedClassLoader);
}
});


C'est du sport mais ça marche !