Mark Reinhold a annoncé quelques points intéressants à la conférence Devoxx 2010 sur le langage Java et sur son blog. En principe Java SE 7 sera là pour la mi-2011. Pour cela, 4 nouvelles JSRs ont été publiées sur le site du JCP cette semaine.
Voici ce que Mark Reinhold a publié sur son blog :
I’m pleased to note the submission of four new Java Specification Requests to the Java Community Process:
* JSR 334: Small Enhancements to the Java Programming Language, by Joe Darcy with help from Jon Gibbons, Maurizio Cimadamore, and many others in Project Coin;
* JSR 335: Lambda Expressions for the Java Programming Language, by Brian Goetz with help from Alex Buckley, Maurizio, and others in Project Lambda;
* JSR 336: Java SE 7 Release Contents, for the enormous team effort that is JDK 7 (the first half of Plan B); and, finally,
* JSR 337: Java SE 8 Release Contents, for the eventual JDK 8 (the rest of Plan B).These JSRs have been a long time coming. They’re now—finally—on the JCP Executive Committee ballot for approval; results should be available in two weeks.
My thanks to everyone who’s contributed to the related OpenJDK Projects
Les JSR’s ont été publiées et sont en attente d’approbation par le JCP, ce qui devrait être fait d’ici début décembre 2010. C’est donc un signe très concret que les choses avancent enfin pour Java.
JSR-336 Java SE 7 Release Contents
La JSR-336 porte sur Java SE 7 (Standard Edition) avec 4 points présentés lors de la Keynote d’ouverture à Devoxx qui sont : la productivité, la performance, l’universalité et l’intégration. Pour la productivité, nous aurons une meilleure gestion des ressources pour les entrées/sorties, des génériques plus simples avec l’opérateur Diamond et une gestion des exceptions moins verbeuse. En ligne de mire : moins de code, toujours une compatibilité et beaucoup de retour sur expérience pour améliorer le langage. Pour la partie performance, il y a au programme l’intégration du framework Fork/Join proposé par Doug Lea, l’un des pères de la partie Thread de Java. Il a d’ailleurs quitté le JCP le 22 octobre 2010. Grâce à la JSR-292, nous aurons aussi un nouvel opérateur dans la JVM, invokedynamic, qui permettra aux langages dynamiques comme Groovy de pouvoir bénéficier d’importants gains de performance au niveau de la JVM.
invokedynamis provides an instruction to the JVM to make a method invocation, but without the types of the return value and the method parameters to be known in the bytecode. It’s quite a technical, bureaucratic reason, but the implication is that it will speed up those interpreter implementations on the JVM, and will also make them more robust. (voir l’article complet)
Toujours à propos des performances, la JSR 203 propose une nouvelle API pour la partie Filesystem, avec une intégration plus fine avec la couche native de votre OS tout en restant portable.
Java SE 7 ce sera aussi beaucoup de nouvelles fonctionnalités comme « Heavyweight/lightweight component mixing » , de nouvelles fonctions de gestion dans JDBC 4.1 grâce à une meilleur gestion de la fermeture des ressources comme les Connections ou un File. Regardez par exemple le nouveau pattern try/with-resources pour gérer intelligemment l’indisponibilité d’une base dans ce post très intéressant.
JSR 337 – Java SE 8 Release Contents
Environ 30% des fonctionnalités prévues ne seront pas dans le JDK 7. La JSR 337 regroupe donc ce qui fera Java SE 8, mais il semble logique que cette liste évolue encore je pense. Alors que Scala 2.8 propose déjà une nouvelle API Collections assez riche, Java proposera dans SE 8 de nombreuses améliorations sur l’API Collections que nous utilisons chaque jour. Avec par exemple la prise en compte des CPUs multi-core, comprenez bien que Java qui était déjà « write once, run everywhere » pourrait rapidement devenir aussi « write once, run everywhere, scale without nightmare » (copyright N.Martignole)
Java SE 8 prendra aussi un peu d’approche fonctionnelle avec le support d’opérations comme map, filter, reduce sur les Collections, travail en partie tiré de l’API Google Guava dont je vous ai parlé il y a quelques temps
La plus grosse nouveauté pour Java SE 8 sera le support des modules via la JSR-277 , afin de ne plus avoir de problèmes avec un Classpath énorme. En bref, vous pourrez définir des JAM au lieu de définir des JARs comme aujourd’hui. Un module JAM sera capable de définir les dépendances nécessaires à son exécution, une sorte de mini projet Maven en quelques sortes, afin de faciliter l’exécution et la configuration d’une application. L’excellent blog Pure Danger couvre tout ceci en détail bien mieux que moi.
Je suis étonné de voir que la JSR-310 sur DateTime ne sera pas dans Java SE 7 mais SE 8. Quand on voit la médiocrité de Calendar, et la qualité de JodaTime, c’est bien dommage.
JSR 334 Améliorations sur le langage Java (Projet Coins
Voici les 6 changements prévus dans le langage Java pour Java SE 7 (liste tirée du blog Pure Danger) :
JSR-335 Support des expressions Lambda pour Java
Concernant le support de expressions lambdas pour Java (les closures), la JSR-335 est dans le package de Java SE 8. Nous n’aurons donc pas de support pour les closures l’année prochaine dans Java mais très certainement en octobre 2012 avec Java SE 8.
Et Apache Harmony ?
Stephen Colebourne a donné une présentation très intéressante à Devoxx sur le futur de Java, je vous en parlerai dans un autre billet. Il a blogué lorsqu’il était à Devoxx. Selon son point de vue, les nouveaux termes de la licence qu’il détaille dans son article ne laissent aucuns doutes sur la volonté d’Oracle : empêcher toutes tentatives d’implémentation de Java par le projet Apache Harmony. Google est plus ou moins aussi visé, avec des restrictions sur la partie mobile (appelé ‘embedded‘ dans la licence). Il termine en expliquant que la fondation Apache devrait quitter le JCP, si ce n’est pas déjà fait au moment où vous lirez ces lignes. Oracle poursuit ce que Sun avait mis en place par rapport à Apache Harmony : un contrôle assez stricte de l’implémentation. Mark Reinhold a confirmé le vendredi matin qu’il n’y aura pas de TCK libre pour le projet Apache Harmony. Il sera difficile de proposer une implémentation de Java au vue des restrictions de la licence. Jugez par vous même :
In addition, to be a Product, a Licensee product that implements a Java Environment Specification must: (a) have a principal purpose which is substantially different from a stand-alone implementation of that specification, while the value-added portion of the product operates in conjunction with the portion that implements the Java Environment Specification; (b) represent a significant functional and value enhancement over any stand-alone implementation of that specification; and (c) not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification.
Enfin pour une fois je crois assez à la date de sortie de Java SE 7, à savoir juillet 2011. Oracle et les anciennes équipes de Sun remettent en marche un processus qui a perdu un an.
A titre personnel je comprends la position d’Oracle (qui était aussi celle de Sun). Nous ne sommes pas dans une industrie qui vie d’eau fraîche et d’amour. Nous ne pouvons pas laisser une entreprise prendre le leadership sur Java ou la plateforme. Si mon côté Geek adore Android et le résultat, qui est finalement ce que Java ME n’a jamais été capable de faire, mon côté Boss préfère que la partie mobile de Java ne soit pas que dans les mains de Google, mais de plusieurs éditeurs comme Oracle, IBM ou Apple. C’est la base de la sécurité de la plate-forme : il faut rester en mode « Guerre froide » où chacun se prépare à dézinguer le voisin, pour le bien de tout le monde.
La suite dans quelques mois…
Hello,
Ma vision est assez lointaine mais c’est un ressenti global de ce que je vois et lis partout sur cette histoire. Concernant la position d’Oracle, elle est assez gênante en ce moment même si je ne la vois que de ma lorgnette et que mon avis est biaisé par le côté « opensource » qui est mon moteur en général.
La question vis à vis de Google (indépendamment du fait qu’ils ont un monopole sur la VM java dans le mobile avec Android ce qui, comme tu dis, peut être ennuyant à terme), c’est « est-ce qu’on peut de nos jours développer une VM (Java ou non) sans encourir les foudres du grand dieu de la VM qui détient tous les brevets logiciels sur les VM? »… C’est très très gênant pour de multiples raisons sans parler de l’absurdité des brevets logiciels sur lesquels ils se battent en ce moment qui ressemblent étrangement au bouton rouge de l’arme nucléaire pendant la guerre froide comme tu l’as si bien dit…
En plus je pense que sur le tas, on peut rajouter le fait qu’il y a des tentatives plus ou moins claires de tater le terrain quant à la monétisation de certains bouts de Java, ce que Sun n’a jamais réussi à faire pour diverses raisons. Certes comme tu dis, oracle fait du business et ils n’ont pas acheté Sun pour continuer à injecter de l’argent dans un goufre sans fond. Le problème que je vois, c’est beaucoup plus l’impact que ça aura sur ma volonté à continuer d’investir à titre personnel du temps dans Java si ce n’est plus vraiment un environnement libre et ouvert…
De plus, le langage est clairement vieillissant et on se retrouve avec un JCP qui avance à la vitesse d’une tortue asthmatique. Certes, la standardisation c’est long mais, quand même, rajouter des lambda et des .each à une List, ça ne demande pas 5ans et je ne pense pas que quiconque a quelque chose à dire contre la nécessité de les avoir!
Tout ça cumulé plus ton idée de guerre froide pour maintenir le statut quo, ça me gratouille le touilleur cérébral :). Et puis je pense que le monde de la technologie, ça ne va nulle part quand il y a un statut quo… jusqu’au jour où un lutin sort d’une boite et pulvérise tout en osant l’impensable dans l’omerta ambiante: il a avancé d’un pas, transgressé une limite et osé dire ou faire ce que les autres n’osaient même plus à force de s’observer le nombril… les exemples sont très nombreux dans la technologie ou l’histoire en général:)… En général le résultat n’est pas bon pour pas mal de gens qui n’avaient rien demandé…
On verra ce que ça donne et j’espère que la raison et l’envie de faire avancer les choses prendra le dessus!
Et puis bravo pour les articles et le travail, c’est très très intéressant!
A+
Pascal