Un grand merci à Olivier Rafal pour son article dans le MondeInformatique à l’occasion de la sortie du livre de Florent sur Android :
JavaFx vs Flex vs Silverlight
Après une période d’inactivité importante due à un beau projet Pierre et Vacances et l’écriture d’un livre sur Android, je reprends ce blog en main !
Je suis tombé dernièrement sur une comparaison des performances entre JavaFx, Flex et Silverlight. Bien que je ne sois pas tout à fait certain de la validité des résultats, il semblerait à vue de nez que JavaFx s’en sorte très honorablement.
Pourtant, je ne pense pas que dans son état actuel, cette technologie pourra décoller.
Le problème n’est pas qu’il faille réapprendre un nouveau langage de script, après tout même si cela demande un petit effort au départ, l’avantage de bénéficier d’un langage (DSL) spécifique à la définition d’interfaces graphiques devrait au final l’emporter.
Le souci n’est pas non plus l’absence d’outils orientés design car Production Suite devrait convenir à la plupart d’entre nous.
Non, le défaut majeur de JavaFx est son manque de discrétion : le temps de démarrage est beaucoup trop long et sans rapport avec Flash, la petite icône Java qui apparait dans la barre de notification est gênante car elle nous rappelle que « quelque chose » se lance, les fenêtres de sécurité sont invasives (heureusement aujourd’hui crossdomain.xml est en partie supporté) et enfin l’expérience utilisateur de l’installation du runtime et des mises à jour de la JVM, avec sa publicité Open Office et sa toolbar Yahoo, plus que moyenne.
A mon sens, tant que ces inconvénients ne seront pas corrigés, il y a très peu de chance qu’émerge un « youtube » s’appuyant sur JavaFx et cela quelles que soient les autres qualités de la plateforme.
Dassault Systèmes
Avec Dassault Systèmes, nous initions notre premier billet de cette nouvelle catégorie qui est « Nos clients ».
C’est un des plaisirs de notre activité ; nous sommes amenés à entrer au sein de diverses entreprises aux métiers très différents. Par exemple, notre dernier client SaaS (l’offre hébergée de notre l’outil collaboratif) est l’institut de massages traditionnels asiatiques Maxam.
Aujourd’hui, l’entreprise présentée est donc Dassault Systèmes. DS est une filiale du groupe Dassault, le célèbre fabriquant d’avions de chasse. DS est un éditeur de logiciels, il s’agit d’ailleurs du numéro 1 français, loin devant les autres. Leur cœur de métier est la 3D et l’un de leurs produits phares est le fameux logiciel de design Catia.
Catia est utilisé par de nombreux industriels dans le monde pour concevoir leurs produits : Airbus, Boeing, PSA, Toyota…
Dernièrement, au travers de leur nouvelle marque 3DVia, Dassault Systèmes a opéré une diversification intéressante, ils se lancent sur le marché grand public et ambitionnent de démocratiser la 3D.
Le site 3dvia.com est un espace communautaire, où les internautes peuvent faire partager leurs créations, c’est l’équivalent de youtube ou dailymotion mais pour la 3D.
Bref, Dassault Systèmes est une société innovante, en bonne santé financière (ceux qui étaient présents à la grandiose soirée d’inauguration de leur campus fin 2008 n’en ont aucun doute) et pour une fois elle n’est pas américaine !
Eclipse RAD
Il y a quelques jours lors d’un déjeuner avec Jean-Marie Damas (un des organisateurs de l’Agile Tour), nous avons évoqué le framework Eclipse RAP (Rich Ajax Platform).
Ce framework n’est pas vraiment tout nouveau et finalement si discret qu’il n’est pas très connu.
L’idée de RAP est d’être le pendant de RCP (Rich Client Platform) dans le monde Web. Il fournit le même environnement « Workbench » et les applications RAP sont implémentées avec les mêmes APIs SWT et JFace que celles tournant sous RCP.
Cette approche universelle peut séduire mais elle me rappelle un peu trop de nombreuses autres tentatives de grand écart qui se sont soldées pour la plupart par des échecs. JDO (Java Data Objects), par exemple, voulait offrir une API unique de persistance et cela quelque soit le système de stockage sous-jacent (BD, XML, fichiers à plat…).
Si l’on souhaite obtenir le meilleur de la plateforme d’exécution il n’est pas souhaitable de concevoir une application web comme une application lourde, une application de bureau comme une application pour mobile…La liste est longue !
JUG Toulouse
Ca y est, Toulouse a dorénavant son JUG !
Il était anormal qu’une ville avec une telle concentration de sociétés technologiques n’abrite pas de Java User Groups.
Pour ceux qui ne le savent, l’idée des JUG est de réunir les utilisateurs et les développeurs de Java dans un esprit d’échange et de convivialité. Nous organiserons des conférences gratuites et ouvertes à tous où seront faites des présentations techniques.
La première est prévue autour de mars/avril, le temps de trouver des sponsors et de mettre en place la logistique.
N’hésitez pas à vous inscrire sur le site ou à nous contacter pour participer.
A bientôt.
Une excellente année 2009
Nous vous souhaitons une excellente année 2009.
Qu’elle soit l’année de réussite de tous vos projets personnels et professionnels !!
eBay
En faisant le ménage sur mon PC, je suis tombé sur cette photo que j’avais prise lors de mon séjour au mois de janvier chez eBay.
La raison de ma venue chez eux était liée à eBox.
Sans pouvoir donner beaucoup de détails pour cause de NDA, eBox est un framework extrêmement ambitieux. Le calendrier initial prévoyait la sortie de la version 1 pour 2008 avec certains modules en open source.
Hélas, l’année s’achève et quand on recherche « ebay ebox » sur google on ne trouve rien de plus récent que 2007 !
J’espère que cela n’est pas le signe d’un deuxième Krach Internet, j’ai rencontré chez eBay des gens passionnants dont les travaux m’ont souvent impressionné et j’aimerais bien en parler !
Installation de Glassfish sous linux
Comment installer glassfish en tant que service sous linux ?
Contrairement à Windows, installer n’importe quelle application sous forme de service n’est pas très compliqué sous un OS de type Unix.
Le billet suivant explique clairement la démarche à adopter.
Malheureusement, un petit hic survient quand on souhaite faire tourner glassfish sur le port 80.
Sous linux, il est purement et simplement impossible de configurer glassfish sur le port 80 si celui-ci ne tourne pas avec le compte root ce qui est toujours regrettable pour des raisons évidentes de sécurité.
Confronté à ce problème, j’ai tout d’abord envisagé (comme à la grande époque de Tomcat) de positionner un apache écoutant sur le port 80 devant glassfish qui serait lui sur le 8080. Je me suis aussi dit qu’au passage grâce à apache je pourrais faire du « Virtual Hosting » et utiliser les quelques applications php dont nous avons besoin.
Cependant, un tour sur internet, a vite calmé mes ardeurs. Les nombreux commentaires de ce post n’encouragent pas à la confiance.
Finalement, après mûre réflexion, j’ai choisi de laisser glassfish s’exécuter avec le compte root. Hormis cet inconvénient qui je l’espère ne tardera pas à être corrigé, les fonctionnalités natives de « Virtual Hosting » de glassfish, l’architecture modulaire OSGi de la version 3 et le repositionnement de la JVM comme une plateforme multi-langage me font penser que glassfish pourrait bien également concurrencer apache !
Nouvelle version majeure disponible
Cette nouvelle version propose en effet de nombreuses nouvelles fonctionnalités :
- la classification des documents par type et la recherche sur ces types
- la recherche dynamique sur les attributs personnalisés et les modèles de documents
- la génération automatique de la référence du document selon un numéro chronologique
N’hésitez pas à tester DocDoku en créant simplement et gratuitement votre compte DocDoku ici.
Upload et download de fichiers avec un web service (suite)
Ce message fait suite à mon précédent billet concernant le download et surtout l’upload de fichiers par Web Services SOAP.
Le bug 29 du projet jax-ws a bien été résolu, avec un petit bémol car la correction ne fonctionne qu’avec les Web Services à base de Servlet et non ceux basés sur les EJB Session. Cependant, pour transférer les données binaires MTOM utilise un transfer-coding de type chunked. Il s’agit d’une fonctionnalité d’HTTP 1.1 permettant d’envoyer ou de recevoir une requête HTTP par morceau.
La version 1.1 du protocole HTTP est vieille de plus de 10 ans. Malheureusement, dans de nombreuses organisations, sévissent encore des proxies web ne supportant que la version 1.0 !
Du coup, il n’est plus possible d’appliquer la propriété JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE sur le proxy du client. On se retrouve alors avec le problème initial ; on risque le « out of memory » côté client en téléchargeant sur le serveur (upload) un fichier volumineux.
Enfin, que les utilisateurs de DocDoku se rassurent, par défaut les échanges de fichiers se font par Web Services MTOM et en cas d’environnement réseau hostile (proxy http 1.0) le client bascule automatiquement dans un mode HTTP basique (multipart/form-data).
Approche SOA
DocDoku a adopté une approche orientée service. Concrètement cela veut dire que toutes les actions accessibles par l’interface graphique le sont aussi par notre API WebServices.
Les url des wsdl sont les suivantes :
Pour interroger ou soumettre des commandes (réserver un document par exemple):
http://www.docdoku.net/webservices/DocDoku?wsdl
Pour le service de téléchargement de fichiers:
http://www.docdoku.net/UploadDownloadService?wsdl
Ces opérations sont réalisées sur l’environnement de démonstration « mydocdoku ».
DocDoku est officiellement Open Source
C’est à l’occasion de la conférence internationale JavaOne organisée par Sun que nous avons officiellement annoncé notre passage en Open Source : GlassFish Technology Partner Showcase.
Vous pouvez désormais vous joindre à notre communauté.
DocDoku offre de nouvelles fonctionnalités
De nouvelles fonctionnalités sont en effet désormais à votre disposition :
- l’export des documents
- l’exploration et la recherche des documents gràce à une interface web (client léger GWT).
N’hésitez pas à découvrir toutes les fonctionnalités de DocDoku sur notre site, dans la rubrique produit.
Vous pouvez également tester DocDoku en créant simplement et gratuitement votre compte DocDoku ici.
JavaOne
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.
Goojet
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 !
Le futur de JSF
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 ?
Upload et download de fichiers avec un web service
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.
JAXB 2.1 avec Java 6
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 !
web services avec JAX-WS
Initialement le client (java web start) DocDoku communiquait au serveur (composants ejb) à l’aide du protocole corba IIOP.
Malheureusement, à tort ou à raison, les proxies http sont souvent le passage obligé pour accéder à internet dans de nombreuses sociétés.
Nous avons donc décidé de passer aux web services. Aujourd’hui cette migration est terminée mais je dois avouer que ce fut plus compliqué que prévu. Voici un bref retour d’expérience :
Au niveau sécurité, les options sont nombreuses, nous avons néanmoins opté, par prudence, pour la simplicité : authentification basic sur du SSL.
Ce poste explique ceci en détails.
Ensuite, la grande difficulté a été d’utiliser nos POJOs sur le client et le serveur sans passer par une couche d’objets intermédiaires mappant le wsdl.
Etrangement, aucun tutorial de Sun n’explique clairement cela et les assistants de netbeans génèrent invariablement cette couche d’objets (avec la commande wsimport) même si le webservice a été créé à partir d’une interface SEI (Service Endpoint Interface).
Sous les conseils d’Alexis, j’ai filé un bug chez netbeans.
Enfin, la solution est la suivante, il faut donc définir une interface pour l’EJB avec endpoint webservice et non simplement annoter les méthodes avec @WebMethod.
Ensuite, importer les classes produites par wsgen également sur le client.
Enfin, récupérer le web service Port par javax.xml.ws.Service.getPort(Class<T> serviceEndpointInterface).