Java au futur | Java le soir

De quoi le futur de Java est-il fait ? On peut se poser la question, et éventuellement s’en inquiéter.

Depuis 1996, Java a évolué à un rythme rapide, pas plus de deux ans entre deux versions. Vient Java 6 en 2006, puis quatre ans de pause, avant l’apparition d’un Java 7 controversé. Certains ont pu dire (et écrire) qu’ils s’agissait d’une sortie à minima. Le rachat de Sun par Oracle, qui a duré plus d’un an, entre autres du fait des problèmes de concurrence autour de MySQL, a porté cette responsabilité, même si les choses ne sont pas si claires. S’en est suivie une période, non pas de troubles, mais plutôt d’inconnues : comment Oracle va-t-il digérer Java, comment cette société, peu habituée à la communauté Open source, va-t-elle se comporter vis à vis du JCP ? En un mot, que Java va-t-il devenir ?

Une période troublée

On se rappelle la façon dont Doug Lea, père de l’API Concurrent a quitté le JCP, et comment, dans sa lettre, il expliquait que la raison en était que le JCP n’était plus le bon contexte pour garantir l’écriture des spécifications d’un Java innovant, et surtout indépendant des volontés industrielles d’Oracle. On se rappelle également le tollé soulevé lorsqu’Oracle a proposé que la société Hologic occupe un siège au JCP. On se rappelle le départ de James Gosling, l’un des créateurs du langage. On se rappelle enfin le soutien d’IBM à OpenJDK, et le début de la fin pour le projet Apache Harmony. Tout cela, c’était il y a à peine plus d’un an.

Dans cette volée de bois vert sur Oracle (qui, il faut bien le reconnaître, constitue une cible de choix !), je ne me rappelle n’avoir entendu qu’une seule voix discordante, celle de Neal Gafter, à la conférence What’s Next. Son propos était alors simple et en deux temps :

Oracle apprend à dialoguer avec la communauté Open source, l’apprentissage n’est pas facile car ce dialogue ne fait pas partie de leur culture, et les procédures de fonctionnement de cette société ne sont pas prêtes ;
le futur de Java est bon, car « now we have someone in charge », c’est-à-dire, il y a quelqu’un aux commandes. Ce qui sous-entendait que, du temps de Sun, ce n’était plus vraiment le cas.

Nous sommes en train de sortir de cette période troublée, durant laquelle on a pu se demander si Java allait devenir le nouveau Cobol, c’est-à-dire un dinosaure, coincé dans une impasse de l’évolution, et destiné à tomber dans l’obsolescence et l’oubli. On n’en sort pas sans y laisser des plumes, so long Apache Harmony.

Aujourd’hui la communication d’Oracle se remet en marche, après un JavaOne 2010 décevant, trop lié à Oracle World, l’avenir de Java s’éclaircit.

Java 8

La roadmap vers Java 8 a été publiée dans ses grandes lignes lors de la décision de sortir un Java 7 en juillet 2011.

Java 8 comportera des lambdas, dont la syntaxe se précise petit à petit, et les virtual extension methods, qui sont nécessaires pour modifier les interfaces existantes, sans changer leurs implémentations. Il s’agit probablement d’un des points les plus attendus de Java 8. Attendus par qui ? Manifestement par peu de gens, très geeks, et très actifs. Il existe déjà des solutions techniques pour ce genre de programmation sur la JVM. Parmi les 12 millions de développeurs Java, combien les utilisent, combien en ont même seulement entendu parler ? Cela dit, même si les lambdas ne seront utilisés que par une infime partie des projets et des développeurs, il reste indispensable de les intégrer au langage, ça sera chose faite.

Sera intégré également à Java 8, un vieux serpent de mer : le projet Jigsaw. L’objet de cette introduction est de spécifier précisément à la fois la version d’une bibliothèque Java (un JAR), et de pouvoir préciser de quoi il dépend. Un nouvel élément standard va arriver : la « classe » (qui n’en est pas une) module-info.java, qui va permettre d’embarquer ces précisions, un peu comme package-info.java permet d’embarquer des informations sur un package (javadoc et annotations notamment). Cette introduction va un peu sonner le glas de notre bon vieux CLASSPATH, du moins tel qu’on le connaît aujourd’hui.

Enfin JavaFX passera en version 3.

Côté navigateur, on annonce l’introduction du projet Nashorn. Il s’agit d’un moteur Javascript sur la JVM, permettant entre autres une bonne interopérabilité entre le code Java et le code Javascript.

Côté téléphonie mobile et tablettes, Java 8 proposera des API pour le support des appareils photos, des accéléromètres, des boussoles et de la géolocalisation.

On y trouve enfin quelques évolutions des APIs existantes et du langage.

Java 8 arrivera dans un an, et la vision qu’Oracle nous en donne est claire : nous sommes sortis du brouillard. Est-ce parce que nous sommes sortis du brouillard que la vision s’éclaircit ? À moins que ce ne soit le contraire, je ne sais pas très bien…

Java 9 et au-delà

Les couineurs rétorqueront à tout ceci que Java 8 était en fait déjà prévu, qu’il ne va embarquer que des choses qui auraient du être dans Java 7, et qu’il ne s’agit que d’une façon détournée de présenter comme des nouveautés des choses qui sont en fait très en retard.

Mais la suite est également prévue : Oracle annonce une nouvelle version de Java tous les deux ans.

Quant au contenu, des idées sont déjà dans l’air (on pourrait même dire « dans les nuages ») pour Java 9. Ces choses sont encore spéculatives, certaines nécessiteront de gros efforts en recherche et développement, il n’est pas impossible que la sacro-sainte compatibilité ascendante soit abandonnée à un certain point. Parmi les idées qui circulent :

Java 9 : la possibilité d’indexer les tableaux en 64 bits, nouvelle version de la Java Native Interface, la possibilité pour plusieurs JVM en fonctionnement sur une même machine physique (ou virtuelle) de communiquer les unes avec les autres.
Java 10 : la suppression des types primitifs (int, double, etc…) en faveur d’un système « tout objet », la réécriture des génériques et la suppression du type erasure.

Le calendrier qu’Oracle annonce nous permet d’espérer une nouvelle version de Java tous les ans. Java 8 est pour le moment prévu pour 2013.

OpenJDK

Le projet OpenJDK devient le projet de référence pour la JVM. La base de code est ouverte, il s’agit d’un projet collaboratif. Oracle annonce qu’il fournira une version compilée et intégrée de l’OpenJDK pour les différentes versions de Windows, de Linux, de Solaris, et avec le code fourni par Apple, une version Mac.

Java Enhancement Proposals

Enfin, notons l’apparition d’un nouvel espace de proposition : le JEP (Java Enhancement Proposal). Il n’est pas si nouveau que cela, puisque son certificat de naissance est daté de juin 2011. La liste des documents de proposition comporte déjà une petite quarantaine d’entrées : http://openjdk.java.net/jeps/0.

L’objet de ce JEP n’est pas de se substituer au JCP mais plutôt de centraliser les propositions des commiters de l’OpenJDK. Au final, la décision d’intégrer la proposition à une version du JDK appartient à la direction du JEP. Il est aussi, et surtout ! de susciter la discussion sur des idées parfois très exploratoires, très en amont d’une éventuelle intégration dans une version du JDK.