Catégorie: Technique

Depuis sa sortie, Leopard, la nouvelle version de Mac OS X, fait pas mal parler de lui pour les nouveautés, la rapidité, les amélioration esthétiques. Il a aussi fait beaucoup de bruit dans la blogosphère Java pour le support de Java qui est resté collé en version 5 alors que Java 6 est sortie depuis presque 1 an... On peut toujours se consoler en se disant que cette nouvelle version vient en 64 bits.

On se disait que s'il y a une catégorie de développeur Java que cela ne gênerait pas, ce serait les développeurs utilisant GWT. En effet, la célèbre API qui transforme le code Java en Javascript, ne supporte pour l'instant que Java en version 1.4.

Et bien ces développeurs aussi vont faire partie des mécontents du Leopard. En effet, sur la dernière mouture de l'OS, le mode hébergé de GWT (qui permet entre autre le débuggage) ne fonctionne pas. Le navigateur apparait puis disparait subitement ou se gèle....
Il semble qu'il y ai plusieurs bugs simultanés à l'origine du problème. Du coté Apple on trouve l'implémentation de JAXP, l'initialisation du sous-système d'AWT et un thread sans ClassLoader... Du coté de Google, le WebKit utilisé pour le navigateur du mode hébergé qui ne fonctionne pas sur Carbon....

Donc un seul conseil à ceux qui font du GWT sur Mac OS X, pas de Leopard avant que ce bug ne soit noté comme résolu...

Je ne sais pas si vous pensez comme moi, mais une excellente façon de se faire une idée sur deux frameworks avec le même objectif (présentation, ORM...), c'est de faire la même application avec chacun de ses frameworks.
Le problème c'est que cela est généralement très consommateur de temps. On passe alors beaucoup de temps dans les documentations de ces deux frameworks. L'idéal est alors de trouver des tutoriels faisant cette comparaison des frameworks.

Dans ce genre d'exercice, j'aime particulièrement celui de Serge Tahé, intitulé "Variations autour d'une architecture web à trois couches". Dans ce tutoriel il développe la même application en utilisant trois techniques différentes pour la couche web : JSP et servlets, puis Struts et enfin Spring MVC. Il s'agit bien sur d'un tutoriel s'adressant plus aux débutants avec beaucoup de détails et traitant de technologies déjà anciennes (au moins pour les deux premières).

Pour ceux qui sont plus intéressés par les frameworks plus modernes, je vous propose aujourd'hui d'aller voir le blog de Carol McDonald. Elle est évangéliste chez Sun et vous avez peut être vu sa présentation sur EJB3 et JPA lors des Tech Days de Paris en mai (sinon la vidéo est disponible). Dans ce blog, elle traite des technologies Java EE et frameworks gravitant autour. Elle propose donc trois entrées avec l'implémentation du même système de pagination du catalogue d'un magasin d'animaux. Dans le premier, elle utilise JSF, un EJB session stateless et JPA, dans le second, elle utilise JSF, Spring et JPA, alors que dans le troisième elle utilise JSF, Seam et JPA.

Depuis longtemps (la version 1) Java a la réputation d'être lent. La lenteur d'exécution s'est beaucoup améliorée pour ne plus être vraie avec les progrès de la JVM, notamment ceux du Garbage Collector et la compilation à la volée (JIT).
Il reste encore un principal reproche à Java que je partage, et qui est le temps de démarrage des applications. Qui n'a pas ralé devant les temps de démarrage des applications en Java, ou qui n'a pas vu ou participé à un troll sur les temps de lancement de la JVM.

Je suis tombé sur cette discussion intéressante : l'auteur ainsi que plusieurs personnes dans les commentaires se plaignent de la lenteur des démarrages d'IDE ou des taches de type build. Beaucoup ont constaté que cela allait plus vite si l'antivirus (notamment McAfee) était désactivé.
J'ai fait les tests sur mon PC avec Norton Antivirus et effectivement les temps de démarrage de NetBeans ou Eclipse sont divisés par 3.

L'explication est que votre antivirus considère les fichiers jar comme des fichiers zip (ce qu'il sont en réalité) et donc l'intégralité de ces fichiers sont scannés lors des accès (lancement, étape de build...) ce qui ralenti énormément l'ordinateur. J'ai déjà vu un Pentium 4 avec 1 Go de RAM inutilisable pendant plusieurs minutes suite à l'ouverture d'un dossier contenant des ZIP que je gardais pour installer un environnement de développement.

La solution pour accélérer le démarrage de l'IDE est donc d'exclure de la surveillance de l'antivirus son répertoire d'installation et pour les builds il faut couper l'antivirus.

L'idéal serait de pouvoir exclure tous les .jar, mais on a déjà vu des virus en Java, enfin le terme est rapide puisqu'il s'agit d'applets exploitant des failles de la JVM de Microsoft (qui l'utilise encore???) et d'une applet qui téléchargeait un trojan Win32. Si vous avez des contre-exemples, n'hésitez pas.

PS : j'aime beaucoup un des commentaires qui dit que dans les ordinateurs dual-core, il y a un processeur pour l'antivirus et un pour notre utilisation....