Avec deux jours de retard je vais vous parler de la sortie de Java SE 6, la sixième incarnation* de la plate-forme standard Java.

Cette nouvelle version n’apporte pas, à priori, des changements révolutionnaires, mais plutôt des améliorations sur plein de plans, certaines très demandés par la communauté de développeurs. Les améliorations qui m’interpellent le plus (depuis l’optique de mes besoins professionnelles) sont :

• La sécurité rentre au fond de la plate-forme, avec intégration native de GSS/Kerberos et de l’authentification LDAP.
• Les web services ont aussi leur place dans la plate-forme standard, avec l’inclusion dans Java SE 6 de Java API for XML Web Services (JAX-WS), version 2.0. Cette JAX-WS 2.0 est une refonte complète de l’architecture des APIs Java pour les web services.
• Java 6 SE inclut le moteur Mozilla Rhino pour interpréter du JavaScript, et laisse la porte ouverte à que d’autres moteurs puissent y être ajoutés. Bientôt sera donc possible d’incorporer des morceaux de code dans votre langage script favori (Python dans mon cas) à l’intérieur de votre code Java.

Ensuite il y a plein d’autres améliorations de fond, dans la gestion de mémoire, la performance, l’incorporation de JDBC 4.0…

En somme, cette nouvelle version semble, à première vue, un petit bijou que je pense que tous les développeurs qui travaillent avec Java vont apprécier. De mon côté, je viens de l’installer, et des que j’aurai du temps je commencerai à la tester à fond!

&nbsp

* : En fait, l’appeler Java SE 6 est du marketing, au moins pour les early adopters comme moi, car dans Java il y a toujours eu une sorte de double nomenclature, une marketing et une autre pour les développeurs. Tout a commencé avec la sortie de Java 1.2, à la fin des années 90s, lorsque tout le monde se mets à l’appeler Java 2.

Mystérieusement, Java 1.3 et 1.4 n’ont jamais reçu un autre nom, mais Java 1.5 a été rapidement rebaptisé Java SE 5. La mode continue avec cette dernière sortie, et elle s’accentue même, car le terme Java 1.6 semble avoir complètement disparu, même le fichier d’installation du JDK (Java Development Kit) est appelé simplement jdk-6-windows-i586.exe (le dernier JDK pour Java 1.5 était jdk-1_5_0_10-windows-i586-p.exe)

Il semblerait que de plus en plus d’éditeurs décident de libérer leur code, dans un mouvement qui s’accélère de plus en plus. Il y a quelques semaines je vous parlait d’une libération de code qui me touchait directement, car je travaille avec tous les jours : l’ouverture du code de Java. Aujourd’hui je vais vous parler d’une autre libération que je considère assez significative, celle de Google Web Toolkit (GWT).

Google Web Toolkit (GWT) est un framework Java de développement de software, qui permet d’écrire d’une façon relativement facile des applications AJAX (du type de Google Maps ou GMail en s’affranchissant de la plupart des particularités liées aux différents navigateurs.

Pour ceux qui avons l’expérience de coder de l’AJAX à la main, l’utilité d’un tel framework est claire. On passe une bonne partie du temps à tester sur toutes les navigateurs possibles dans toutes les plate-formes qu’on a sous la main, et à corriger l’infinité de bugs qui apparaissent en executant le code dans chaque navigateur, toutes les subtiles incompatibilités qui font du codage en AJAX quelque chose plus proche de l’art que de la science. Avec GWT, on écrit tout en Java, un langage solide et bien carré, et lui il compile ce Java en HTML+JavaScript bien compatible avec tous les navigateurs (au moins avec Firefox, IE, Opera et Safari).

Jursqu’au présent, GWT était gratuit pour une utilisation personnelle, mais pas libre. Je pense que cette libération va permettre que certaines entreprises qui travaillent déjà sur Java (comme celle dont je travaille actuellement) basculent sur cet outil pour les briques AJAX de leurs applications web.

L’annonce a été fait dans le blog officiel de Google, et détaillé dans le blog du GWT. La licence choisi est Apache 2.0, encore une fois une licence plutôt classique (comme Java, qui va être libéré sous une licence GPL v2) et non un truc exotique qui ferait plus difficile son adoption.

Dans le billet du blog GWT, ils expliquent comment le choix de libérer était logique, car depuis le début la mission de l’équipe GWT était :

Pour que le développement soit vraiment ouvert, ils ont créé un projet google-web-toolkit dans Google Code, et ils ont libéré aussi toute la documentation sous une licence Creative Commons.

En résumé, un autre beau exemple de libération de code par un des grands acteurs du web.

Même si j’aimerais bien vivre de mon blog, on est encore bien loin. Depuis déjà quelques années, c’est Java qui me permet de payer mes factures. Toute nouvelle qui touche donc ce langage est assez importante pour moi.

Mon histoire avec Java commence en 1998, lorsque j’ai fait un stage de six mois chez IBM. J’avais déjà fait un peu de Java, chez moi, pour tester ce nouveau langage qui semblait aussi intéressant, mais chez IBM j’ai été obligé à monter rapidement en compétence en travaillant dans un projet de migration vers Java 1.1 chez Caja Madrid. Depuis je m’était centré plus sur le côté télécom de ma carrière, mais à la fin de mon doctorat je suis revenu dans le monde Java avec des missions de prestation pour des SSII. A l’époque, l’idée de qu’un jour Sun allait libérer le code de Java faisait rire (mais à l’époque on pensait la même chose d’une éventuelle libération de Solaris, par exemple…).

Tout ça pour dire que je suivait avec intérêt toutes les nouvelles sur la libération du code source de Java sous une licence open source. On avait entendu toutes les rumeurs : libération totale, libération partielle, licence spécial Sun, licence BSD…

La semaine dernière une nouvelle rumeur, en apparence très sérieuse et documentée, a parcouru la blogosphère anglo-saxonne, Slashdot l’avait relayé : Java allait être libéré sous une licence GPL v2.

Je n’avait pas voulu bloguer sur ça, car il n’y avait pas de confirmation officielle. Et la confirmation officielle arrive aujourd’hui, dans le site officiel de Sun. Et en plus, un des blogueurs de Sun nous fait un décryptage du pourquoi et comment de cette libération de Java.

Pour fait courte la partie technique, je reprends la formule de Tim Bray :

Pour moi, c’est une manoeuvre qui va dans le bon sens, surtout pour Sun. Depuis le début, ils ont offert toutes les outils Java gratuitement (mais avec code fermé), et cela a été un des facteurs clés dans le succès du langage. Ils donnaient donc à la communauté des utilisateurs, mais en avant le code fermé, ils ne profitaient pas des éventuelles améliorations que la communauté pourrait faire dans le code.

L’un des arguments en contre était le risque de fork, que des groupes de hackers, des chercheurs ou des passionnés prennent le code source de Java, le modifient et proposent des versions de Java incompatibles entre elles. Mais avec le parapluie du TCK (la suite d’outils de test qui permettent de certifier un produit comme “compatible avec Java”) et des marques registrées, le risque n’existe pas, car ils ne pourraient pas appeler leur projet Java (comme pour Firefox, on peut créer et même vendre des versions modifiées de Firefox comme Flock, mais on ne peut pas les appeler Firefox).

Sur ça, la position de Sun est claire :

Cependant, il y a un risque énorme de voir pousser des langages ou des machines virtuelles basées sur celle de Java, avec d’autres noms, et taillées pour des besoins plus spécifiques. Mais cela est, à mon avis, une bonne chose. Et ce qui est encore mieux, Java pourra profiter des améliorations faites dans ces projets. Tout le monde gagne donc…