Cette semaine il se déroule à San Francisco la plus importante conférence internationale sur Java : Java One. J’aurais bien aimé pouvoir y aller, mais ça n’a pas pu se faire^*, alors je suive la conférence à distance, par des podcasts dans le site officiel, et des billets des blogueurs assistants.

La plus remarquable des nouvelles dans ce début de conférence a été sans doute l’annonce de JavaFX. JavaFX se veut l’alternative Java pour le développement des Rich Internet Applications (RIA, applications web avec un interface rich). Jusqu’à il n’y a pas si longtemps, les seuls concurrents dans cette catégorie étaient JavaScript et Adobe Flash. Cependant ces derniers temps les plate-formes de développement de RIAs s’ont multiplié comme des champignons dans une cave tiède et humide. De l’Adobe Flex, au projet libre OpenLaszlo, en passant par le future Microsoft Silverlight, la mode est aux RIAs et tous le monde cherche à obtenir une partie du gâteau.

Dans un marché soudainement si saturé, quelles sont les chances pour un produit comme JavaFX ? Peut-être je me trompe, mais je pense que assez bonnes, car à mon avis JavaFx compte avec plusieurs atouts de taille :

• IDE multi-plate-forme : Là où les IDE de Adobe Flash/Flex ou de Microsoft Silverlight ne marchent que sur Windows et où OpenLaszlo n’a pas d’IDE proprement parlant, JavaFX aura un IDE intégré dans Eclipse ou Netbeans. On pourra développer aussi bien dans Windows que Linux, MaxOS ou même dans des environnements plus “exotiques” comme FreeBSD.
• Environnement d’exécution multi-plate-forme : Je ne parle pas de que l’environnement d’exécution puisse tourner sur des différents systèmes d’exploitation, car la plupart de ces plate-formes permettent une exécution au moins sur Window, Linux et MacOS (Microsoft Silverlight étant pour l’instant la vilaine exception, car il sortira sans aucun support Linux). Car dans le cas de JavaFX, multi-plate-forme veut dire que les scripts JavaFX pourront s’exécuter sur tout type de terminal, d’un téléphone portable à une télé, en passant par un PDA et un ordinateur. Le mantra de Java, développez une fois, exécutez partout, sera pleinement respecté dans JavaFX.
• Gratuité des outils de développement : Dans la pure tradition Java, les outils de développement sont gratuites. Si vous voulez commencer à jouer avec les premières versions de ces outils, il vous suffit d’aller sur le site des développeurs de JavaFX.
• Popularité du langage Java : Java est un des langages les plus populaires (peut-être le plus populaire). Les développeurs habitués à Java (autant dans sa forme standard que dans ses déclinaisons entreprise ou mobile) seront sans doute attirés par le fait que JavaFX se base sur Java et qu’il permet d’accéder à toute la richesse de l’API de Java.

En tout cas, étant donné que Java c’est mon gagne-pain depuis quelques années, je place beaucoup d’espoirs sur la sortie de JavaFX, car il ouvre toute une série de possibilités qu’avant on ne pouvait envisager sans changer toutes les outils de développement et exécution. On verra si le temps nous montre qu’il est à la hauteur de ces espoirs…

^* : mon collègue de bureau Fred a eu la chance d’y aller, et j’imagine qu’il lira ce billet depuis San Francisco… Alors n’oublies pas de nous envoyer une carte postale, Fred!

Mises à jour :

• J’ai trouvé un billet très intéressant sur l’aspect développez une fois, exécutez partout de JavaFX dans le blog du CEO de Sun. Et comme bonus, il a une belle image de à quoi ça peut ressembler un téléphone portable avec un interface JavaFX… et cela ressemble beaucoup à un iPhone, à mon avis ;)
• Je viens de télécharger le plugin JavaFX pour Eclipse, des que j’aurai un peu de temps libre je vais commencer à jouer avec. Je vous raconterai ce que cela donne…

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…