Les premières Release Candidates de Java 8 sont apparues début Février. La toute première, b128, le 4 Février, et une seconde annoncée sur la liste de diffusion OpenJDK une semaine plus tard.
Java 8 RC2 corrige un défaut sérieux dans sa nouvelle API Comparator, dans laquelle le nouveau thenComparing() avait une restriction de type non nécessaire. D'après le rapport de bug:
Les méthodes suivantes de java.util.Comparator requièrent que le type U étende java.lang.Comparable.
<U extends Comparable<? super U>> Comparator<T> thenComparing( Function<? super T, ? extends U> keyExtractor, Comparator<? super U> keyComparator);
Cependant, cette restriction est superflue car keyComparator est utilisé pour comparer les objets de clé extraits.
Java 8 RC2 corrige aussi une permission de lecture sur Mac OS X. Les Release Candidates peuvent être téléchargées depuis https://jdk8.java.net/download.html.
D'après le suivi de bug du JDK 8, la release coincidera avec la Saint Patrick le 17 mars. Au moment de la rédaction de cet article, il reste 3 tickets non résolus, tous liés à la documentation.
Toujours à propos de Java 8, Drew Stephens a récemment publié des chiffres montrant que les implémentations des nombres atomiques sont plus rapides. Mark Reinhold a aussi proposé que les Stripped Implementations (NdlR: une fonctionnalité qui aurait permis d'assembler des versions allégées de la jvm avec des applications embarquées, ne gardant que les parties de la JVM utiles au code de l'application) soient abandonnées pour ce qui est de Java 8, citant des problèmes légaux comme raison.
Nouvelle Implémentation des Nombres Atomiques
En supplément des Lambdas de Java 8 (335) et la nouvelle API Date et Heure (JSR 310), Java 8 contient des implémentations de nombres atomiques qui sont très importantes pour certaines classes d'applications multi-threadées. Drew Stephens, Ingénieur Principal chez Palamino Labs, a récemment écrit à propos de l'ajout de LongAdder et DoubleAdder.
Moins flashy mais tout aussi important pour certaines classes d'applications multi-threadées, l'ajout de LongAdder et DoubleAdder, des implémentations atomiques de Number qui fournissent des performances supérieures à celles de AtomicInteger et AtomicLong en cas de contention par de multiples threads.
Du benchmarking simple illustre la différence de performance entre les deux. Pour les benchmark qui suivent nous avons utilisé une instance EC2 m3.2xlarge, qui donne accès aux 8 coeurs d'un Intel Xeon E5-2670.
Avec un unique thread, le nouveau LongAdder est un tiers plus lent, mais quand les threads sont en contention pour incrémenter le champ, LongAdder montre sa valeur. Notez que la seule chose que chaque thread fait est d'essayer d'incrémenter le compteur - ceci est un benchmark des plus extrêmement synthétiques. La contention ici est plus haute que vous ne voudriez en avoir dans la plupart des applications réelles, mais parfois vous avez besoin de ce genre de compteur partagé, et LongAdder sera alors d'une grande aide.
Drew continue de montrer que AtomicLong est un peu plus rapide avec des threads uniques. Cependant, il est 4 fois plus lent avec deux threads, et presque 5 fois plus lent quand le nombre de threads correspond au nombre de coeurs. Il note aussi que "La performance de LongAdder est constante jusqu'à ce que le nombre de threads excède le nombre de coeurs physiques du CPU".
Stripped Implementations Abandonnées (dans cette release)
Les Implémentations Allégées (Stripped Implementations) sont une fonctionnalité proposée de Java 8 qui permet de personnaliser une implémentation de Java SE pour la packager avec les applications destinées à tourner dessus. Les éléments sur lesquels le code de l'application ne dépend pas peuvent être retirés. Ce type d'implémentation est probablement utile pour ceux qui veulent intégrer Java à des objets (de l'électro-ménager par exemple).
Mark Reinhold a récemment proposé que les Stripped Implementations soient retirées de Java SE 8. Il a cité des raisons légales à cela.
De manière à préserver la compatibilité et à se prémunir contre la fragmentation, la fonctionalité Stripped Implementations de Java SE 8 requiert des changements non triviaux à la licence TCK.
J'ai travaillé avec le département juridique d'Oracle sur ces révisions depuis un certain temps maintenant. Nous avons un brouillon initial mais à ce stade, malheureusement, je ne crois pas qu'il y ai suffisamment de temps pour les membres de ce Groupe d'Experts, les membres du Comité Exécutif et les autres partis intéressés pour relire et commenter ces changements.
Je propose de ce fait de retirer la fonctionalité des Stripped Implementations de Java SE 8. Cela ne demandera que des changements à la spécification et aux règles TCK - pas de changements véritables au RI, ou aux tests réels TCK.
Reinhold a aussi écrit qu'il pense que cette fonctionalité est importante pour le futur de la plate-forme Java et qu'elle pourrait être ajoutée à une livraison avant Java SE 9.
La release de Java 8 est juste au détour du chemin. Des dates plus faciles, des closures, une meilleure concurrence et un nouveau moteur JavaScript sont juste à un mois de distance ! Mettrez-vous Java à jour ? Si non, y a t'il une raison technique qui vous en empêche?