Si vous travaillez de près ou de loin avec le langage Java, vous êtes sûrement au courant du feuilleton politico-juridico-technologique autour du langage depuis l’acquisition de Sun parOracle l’année dernière.

L’un des premiers chapitres était le départ de James Gosling, le concepteur de Java. Après, les actions d’Oracle autour de Java sont devenus de moins en moins claires, de il y a eu le procès contre Google sur l’utilisation de la JVM sur la plate-forme Android.

En réponse, Google a annoncé que ils n’iront pas à JavaOne. Cette absence est très symbolique, compte tenu que beaucoup d’anciens employés de Sun, parmi lesquels des grands noms de Java comme Joshua Bloch travaillent à présent sur Google. Mais lorsqu’on sait que James Gosling ne sera pas là non plus, on voit à quelle point Oracle a réussi à se couper du noyau dur des développeurs du langage.

Les actions d’Oracle sont vues par beaucoup de développeurs Java comme une attaque contre la communauté de logiciel libre autour de Java. Lundi dernier, James Gosling a posté sur son blog un billet en proposant un t-shirt à porter lors du prochain JavaOne, pour rappeler à Oracle ses engagements de libérer Java.

Pour apporter ma petite pierre au bâtiment, j’ai fait une version française du motif du t-shirt :

Je n’ai pas retouché le dessin de Mr Gosling, je suis parti de zéro avec Inkscape. Cependant, le dessin est sont idée, il est donc propriétaire, et s’il me demande de retirer ma version je le ferai sans hésitation.

Je compte me faire un t-shirt à titre personnel, et si Mr. Gosling m’autorise, je vais le proposer aussi en t-shirt sur Comboutique et Spreadshirt. A prix coûtant bien entendu (pas question de faire un bénéfice quelconque sur ça).

Mise à jour

Suite à des suggestions reçues par mail, j’ai changé sur le dessin la phrase Faites Oracle tenir parole par Incitez Oracle à tenir parole.

Compatibilité ascendante et descendante

L’un des avantages de Java lorsqu’on doit entretenir un parc applicatif étendu c’est la compatibilité ascendante de la machine virtuelle Java.

En effet, à quelques exceptions près, un code Java compilé en 1999 avec le JDK 1.1 marche aujourd’hui lorsqu’on l’exécute avec une JVM 1.6. Par contre, l’inverse n’est pas vrai, la machine virtuelle Java n’assure pas une compatibilité descendante, i.e. une classe compilée pour la JVM 1.6 ne s’exécuterait pas sur une JVM 1.5.

Normalement cela n’est pas un problème… sauf quand on doit impérativement exécuter un code dans une ancienne version de la machine virtuelle. Dans ce cas là, on a intérêt à s’assurer que le code a été compilé pour cette JVM (ou pour une JVM plus ancienne) avant d’essayer de l’exécuter.

Comment peut-on donc savoir la version de la JVM utilisée comme cible de la compilation une classe Java ?

Pour garantir que les applications Java puissent d’exécuter à l’identique sur les différents plateformes, les fichiers .class ont un format figé. De cette façon, lorsqu’on compile du Java sur n’importe quel plateforme, on obtient les mêmes fichiers .class.

Les fichiers .class ont donc une structure fixe, ils sont découpés en dix sections (certaines à taille variable), et c’est dans la deuxième section qu’on va trouver la réponse à notre question.

La première section, c’est le magic_number. Ce paramètre, codé sur 4 octets, permet à la JVM de reconnaître le fichier comme une classe Java. Le valeur de ce magic_number est 0xCA 0xFE 0xBA 0xBE (CAFEBABE).

Les 4 octets suivantes définissent la version de la JVM utilisée comme cible de la compilation. Les deux premiers octets sont la version mineure (normalement 0) et les deux suivants indiquent la version majeure. C’est cette version majeure qui donne donc la réponse à notre question :

Pour voir donc la version de la JVM utilisée comme cible lors de la compilation d’une classe, il suffit d’ouvrir la classe avec un éditeur hexadécimal (moi j’utilise la commande hexdump -C) et regarder le début du fichier, qui sera de la forme CA FE BA BE 00 00 00 XX où XX indique la version.

Par exemple, pour une classe compilée pour JVM 1.5 on aurait CA FE BA BE 00 00 00 31

Merci à Mathias de m’avoir mis sur la piste. Ce soir je me coucherai moins bête…

Ce matin, après une mise à jour de certains paquets Ubuntu, mon Eclipse ne démarrait plus. Le processus de démarrage semblait bien, se passer, mais à la place de l’interface de l’application, je n’avais qu’une fenêtre de dialogue vide.

En regardant les logs dans eclipse/.metadata/.log, j’ai vu que au moment de la construction de l’interface, Eclipse tombait en erreur :

Après avoir regardé un peu à droite et à gauche, il se trouve que cette erreur est due à des problèmes avec XulRunner, l’environnement d’exécution d’applications XUL utilisé par Eclipse pour son interface.

J’ai actuellement trois versions de XulRunner installées sur ma machine : XulRunner 1.9.0 (correspondant en gros à Firefox 3.0), XulRunner 1.9.1 (correspondant à Firefox 3.5) et XulRunner 1.9.2 alpha (qui serait celle qui correspond à Firefox 3.6 alpha). En faisant xulrunner -version, j’ai vérifié que la version de XulRunner utilisée par défaut est la 1.9.1.

Apparemment, XulRunner 1.9.1 casse la compatibilité des binaires compilés pour XulRunner 1.9.0, dont Eclipse 3.4. J’ai donc modifié le fichier eclipse/eclipse.ini en ajoutant le path de mon XulRunner 1.9.0 :

Et le problème a disparu. Reste à savoir pourquoi le problème est apparu d’un coup ce matin, car j’ai XulRunner 1.9.1 installé depuis des mois, mais cela est une autre histoire…

Après l’humour geek, revenons à un billet un peu plus technique…

Je l’ai dit souvent, et je le répète, internet arrivera toujours à me surprendre.

Hier je discutais avec de collègues sur comment faire communiquer un script shell avec une application web en Java sur l’intranet. La solution la plus simple était sans doute de faire un point d’entrée sur l’application Java, une petite servlet à laquelle on appellerait depuis le script shell via wget ou curl.

Quelqu’un a suggéré, à moitié en blaguant, d’implémenter la communication sur la forme d’un vrai web service (WS) en SOAP, avec son WSDL et tout. Je ne vais pas rentrer dans les avantages ou les inconvénients des WS en SOAP vs une approche REST, car c’est un peu philosophique comme débat. Il suffit de dire que pour ce petit besoin c’était un peu exagéré de devoir implémenter un WS SOAP, et on est donc partie sur l’approche REST avec une simple appelle sur l’URL de la servlet.

Ce matin le sujet est revenu dans la conversation et je me suis mis à penser comment on aurait pu faire si on avait eu vraiment besoin d’utiliser des WS complexes, avec SOAP, sécurité, cryptage…. Dans ma tête il aurait fallu développer le client WS à part, en Java par exemple, et appeler ce client depuis mon script shell.

Et là, je me suis dit qu’à coup sûr il y aurait quelqu’un sur le net qui a implémenté un client WS SOAP fait pour être appelé depuis en ligne de commandes, une sorte de wget pour des appels webservice. Un passage rapide par Google m’a permit de confirmer mon intuition, il y en a bien des implémentations de clients SOAP utilisables depuis un script shell !

Je suis allé donc voir WSF/C, un framework pour des WS écrit en C standard, compatible avec les implémentations Apache WS-* (dont Axis2). Ce framework inclut un client WS en ligne de commandes, wsclient, que on peu utiliser d’une façon semblable à wget ou curl.

L’implémentation est assez complète, pouvant supporter des différentes schémas d’authentification et cryptage. Le programme se pilote depuis la ligne de commandes, d’une façon assez simple pour ceux habitués à utiliser des programmes sur le shell.

Par exemple, pour appeler les WS Amazon, il suffit de faire :

où item_search.xml est un fichier XML respectant le format SOAP des WS Amazon. Par exemple :

Est-ce que c'est utile ? Peut-être pas pour une utilisation quotidienne, mais lorsqu'on veut faire des tests sur un serveur n'ayant pas d'interface graphique (ne pouvant donc pas utiliser des outils telles que SoapUI), c'est une façon beaucoup plus rapide, simple et sympa que devoir tout faire avec curl ou devoir programmer un client Java pour le faire.

Bref, un petit outil curieux pour garder sous la main au cas où on pourrait en avoir besoin...

En septembre dernier j’ai commencé à préparer la certification SCJP (Sun Certified Java Programmer), avec l’idée de qu’elle soit une première étape dans la chaîne des certifications Sun, suivie par d’autres certifications jusqu’à éventuellement culminer dans la SCEA (Sun Certified Enterprise Architect).

Après avoir passé la certification SCJP en novembre, je m’étais donc engagé dans la phase suivante, la préparation de la SCWCD (Sun Certified Web Component Developer).

Mon manque de temps de ces derniers mois, et le conséquent ralentissement du blog, ont fait que je n’ai pas parlé de la préparation de cette certification comme j’avais fait avec la précédente.

J’ai donc passé l’examen mardi dernier, à Rennes cette fois, et je l’ai obtenu ma certification SCWCD avec 84% de bonnes réponses.

Comme pour la dernière fois, les derniers jours de préparation ont été assez intenses, sauf qu’à différence de la dernière fois, je n’ai pas pu encore trop me reposer, car j’ai une semaine assez chargé au travail. Vivement le week-end !

Avant de finir le billet, je tiens à féliciter mon collègue Raphaël, qui a aussi obtenu sa SCWCD avec un très remarquable score de 97% !

Je vous ai souvent parlé ces dernières semaines de ma préparation pour la SCJP, et je vous ai raconté comment j’avais du mal à me mettre dans une logique d’étude semblable à celle que j’avais en école d’ingénieurs.

Le passage de la SCJP était une première étape dans la chaîne des certifications Sun, qui devait se suivre par d’autres certifications jusqu’à éventuellement culminer dans la SCEA (Sun Certified Enterprise Architect). A priori j’avais pensais faire une pause après la SCJP et commencer à préparer la certification suivante en début d’année, question de ne pas me mettre de la pression. Mais après le succès à la SCJP je me suis dit qu’il me fallait profiter de m’être enfin mis dans une démarche d’étude régulier, et que si je m’arrêtais un mois et demi j’allais ensuite avoir encore du mal à m’y remettre.

En conséquence, en fin de semaine dernière j’ai commandé le bouquin pour la SCWCD, Head First Servlets & JSP. Je l’ai reçu lundi dernière, et j’ai commencé de suite à le lire.

Etant donné que ça fait quelques années que les applications web Java sont une partie centrale de mes activités professionnelles, pour l’instant tout me semble connu. Mais avec la SCJP j’ai appris à me méfier, car il y a plein de petits détails qui peuvent s’avérer problématiques dans l’examen, même pour un développeur chevronné.

Maintenant il me faut réfléchir pour la date…

Ca fait des semaines que je vous parle de ma préparation pour la SCJP, alors je pense que je dois clôturer la série en vous disant le résultat.

J’ai donc passé mon examen aujourd’hui à Nantes, et j’ai obtenu un score de 83%, ce que veut dire que j’ai eu ma SCJP !

Et pour tenir l’habitude jusqu’à la fin, il n’y a pas eu de billet sur la SCJP sans dessin. Je vous laisse un autre gribouillage, crayonné, encré et colorié entre des exercices et des examens blancs. On pourrait l’appeler Dur dur d’être Batman…

Les trois derniers jours de préparation ont été assez intenses, et maintenant que la pression est retomber je n’ai qu’une envie, faire une bonne nuit de sommeil. Mais avant arrêter, je tiens à finir le billet en félicitant mon collègue Raphaël, qui a aussi obtenu sa SCJP avec un remarquable 94% de bonnes réponses. Ca, c’est du bon boulot !

On entre dans la dernière semaine avant mon examen de SCJP, et je me rends compte que comment les choses ont changé ces dix dernières années. A l’époque où j’étais à l’ETSIT, la quinzaine avant les examens était l’époque la plus productive, j’arrivais à bosser à un rythme soutenu, quitte à faire des nuits presque blanches jour après jour.

Maintenant, le boulot la semaine et ma fille le weekend ne me laissent pas le choix, la journée je suis occupé et lorsque je dois me mettre à bosser le soir je suis déjà fatigué, et même si j’arrive à passer des heures devant le bouquin, la productivité est loin d’être aussi élevée que je voudrais.

Il va falloir que je profite bien de la journée fériée de demain, ainsi que du weekend prochain, si je veux aller à la certification avec une certaine sérénité.

Sinon, comme vous pouvez vous douter, je ne trouve pas trop le temps de m’occuper d’autres choses ces jours-ci, alors à la place d’un dessin je vais vous laisser un autre de ces gribouillages griffonnés vite fait sur le coin d’une feuille. Cette fois, la contre-partie du Supergribouillé optimiste et souriant de la dernière fois, le héros torturé qui se cache derrière une masque aux traits d’une chauvesouris, le ténébreux Batgribouillé.

Je me dis que peut-être demain entre deux examens blancs j’aurai le temps de le passer sur Inkscape…

Hier soir je n’ai pas eu le temps d’avancer ma SCJP comme j’aurais voulu, ce qui ajoute encore un peu plus à la pression dont je vous parlais. Du coup, je compte sur les soirées du weekend pour rattraper un peu le retard afin d’entamer la semaine prochaine avec plus de sérénité.

J’ai déjà lu deux fois le bouquin, et maintenant je me centre sur les questions et les examens blancs, même si cela me fait souvent revenir au livre pour bien comprendre le pourquoi du comment des réponses. Dans le CD qui accompagne le livre de préparation il y a deux examens blancs équivalents au vrai test, mais je n’ai pas encore voulu les attaquer, je préfère les réserver pour la semaine prochaine.

Un bon site pour trouver du soutien, et pour se rendre compte de plein de détails sur la SCJP, c’est JavaRanch, surtout son forum dédié à la préparation de la certification. Je pense que j’y vais passer pas mal de temps la semaine prochaine…

Sinon, ce matin avant de partir au travail j’avais envie de me vider un peu la tête, j’ai donc pris un petit quart d’heure pour passer sur Inkscape le gribouillage de hier. Voici le résultat :

Je trouve plutôt marrant les Supergribouillé, je pense que maintenant je vais devoir m’occuper de lui donner un contrepoint en dessinant un Batgribouillé…

Avec tous ces billets sur la dernière version Ubuntu, mon blog était en train de devenir trop mono-thématique. Revenons donc à d’autres sujets…

C’est la dernière ligne droite avant mon examen de SCJP, et depuis quelques jours je me suis mis en mode examen, en passant une bonne partie de mes soirées devant le bouquin à essayer de comprendre les subtilités les plus subtiles du travail du compilateur Java. Car comme mon collègue Raphaël dit, cette première certification Java vise à qu’on devient un compilateur Java vivant plus qu’à tester si on sait vraiment développer en Java (pour cela il y a les certifications suivantes, en commençant pas la SCJD).

Du coup ces derniers jours je trouve de moins en moins du temps pour d’autres sujets, que ça soit le blog, des dessins, internet, World of Warcraft ou même la simple veille technologique. Et je ne pense pas que ça s’arrange avant le 18 novembre, date de mon examen. Ca me rappelle ces semaines à la veille du période d’examens à l’ETSIT, il y a déjà une dizaine d’années. Nostalgie, quand tu nous tiens…

Alors les seuls dessins nouveaux sont des petits gribouillages au crayon sur le coin d’une feuille, faits de façon presque automatique pendant que je suis occupé à d’autres choses. C’est le cas de ce Supergribouillé prêt à sauver le monde et protéger les veuves et les orphelins :

Si par hasard je trouve quelques minutes pour le passer sur Inkscape, je vous le montrerai, fier avec sa cape rouge et son slip par dessus son pantalon