Catégorie: 7 (Dolphin)

Les JSRs sont des documents primordiaux du Java Community Process, puisqu'il s'agit des documents de travail qui seront soumis aux votes de la part des membres du-dit JCP.

Longtemps attendu, la JSR de Java 7 est enfin là, et elle n'est pas seule, puisqu'on y retrouve en tout quatre nouvelles JSRs :

• JSR 334: Small Enhancements to the Java™ Programming Language (Le projet Coin pour Java 7)
• JSR 335: Lambda Expressions for the Java™ Programming Language (le projet Lambda pour Java 8)
• JSR 336: Java™ SE 7 Release Contents
• JSR 337: Java™ SE 8 Release Contents

» Lire la suite!

On se dirige donc vers un JDK7 "amoindri" qui sortirait mi-2011, suivi par un JDK8 un an plus tard. En effet Oracle a mis à jour la page des fonctionnalités prévus pour le JDK7, et il semblerait bien que le "plan B" ait été adopté.

On a donc la confirmation des principales nouveautés de Java 7 :

• Le support des langages dynamiques via la JSR 292 (InvokeDynamic).
• L'évolution du langage via le projet Coin, qui est uniquement amputé du support des collections.
• L'API de Concurrence (JSR 166).
• L'API NIO.2 qui apporte entre autre un meilleur accès au système de fichier et des channels asynchrones.
• La standardisation des modifications apportées par Java 6 upadate 10 (LnF Nimbus, JLayer, fenêtres transparentes non-rectangulaire).

» Lire la suite!

Mark Reinhold, qui dirige les travaux sur la plateforme Java chez Oracle, vient de publier sur son blog personnel un billet intéressant quand à la prochaine version de Java : Re-thinking JDK 7.

Comme on s'en doutait un peu, suite au rachat de Sun par Oracle et à l'ajout de nouveaux projets (Lambda, Jigsaw et Coin), le planning originel n'a pas été respecté (Le JDK7 aurait dû sortir demain !) alors que la version actuellement en développement n'a même pas encore atteint le status de "feature-complete", et qu'il manque toujours plusieurs JSRs...

Et dans ces cas là, il y a toujours une bonne et une mauvaise nouvelle...

» Lire la suite!

J'essaye de suivre régulièrement les mailing-lists concernant l'évolution du langage Java. En particulier celle des projets Coin et Lambda, traitant principalement de l'évolution du langage. Il est intéressant de voir à quel point chaque petit détail peut prendre une importance capitale, que ce soit pour des raisons de compatibilités et voir même philosophique...

Bien que ce soit des langages orientées objets, j'ai toujours dit que les C++, Java et C# offrait chacun une approche différente de la POO.

J'avais déjà bien constaté cela il y a quelques années en ce qui concerne les Templates/Generics. Il en est de même aujourd'hui avec la proposition de "Defender Methods" de Java 7 en comparaison des "Extension Methods" de C# 3.0. Car si prime abord cela semble très proche, cela implique en fait des concepts très différents !

Pourtant on part d'une même problématique dans les deux cas : l'ajout de nouvelles méthodes dans une interface existante implique forcément des incompatibilités avec toutes les classes qui l'implémente. Bien sûr dans un petit projet cela n'a pas vraiment d'importance, mais dès qu'on touche à des librairies standard ou très répandus ces changements s'avère impossible !

Pourtant, les interfaces sont utilisées massivement et ne possèdent malheureusement pas toujours une API complète dès leurs créations. La solution consiste alors à utiliser des méthodes static dans une classe utilitaire pour faire le travail, ce qui n'est pas sans défaut et surtout assez éloigné de l'approche "orienté objet"...

» Lire la suite!

En fin d'année dernière, le report de Java 7 laissait envisager l'intégration des closures. Cela a donné naissance au projet Lambda dont l'objectif était de regrouper les différents travaux afin d'en sortir une spécification claire et fonctionnelle quitte à se passer de certain "power-concept".

Il en ressort une proposition d'expressions Lambda relativement allégée vis à vis des multiples et très complètes propositions de closures qui ont pu être proposées par le passé. Mais cela s'accompagne également de nouveaux concepts fort intéressants (Exception Transparency, Method References, Defender Methods).

Voyons voir de quoi il en retourne...

» Lire la suite!

Après le multi-catch/rethrow et depuis la version b105, les derniers builds du JDK 7 intègrent désormais le support des try-with-resources (bloc ARM), ce qui permettra enfin de pouvoir gérer proprement la fermeture des ressources de manière simple et efficace.

Voilà enfin une syntaxe claire et précise pour libérer les ressources proprement et sans erreur...

» Lire la suite!

Le projet Lambda, poussé par Oracle a peut-être engendrer un nouveau bébé, les "public defenders methods", dont l'objectif est de permettre de faire évoluer les interfaces Java.

De prime abord cela n'a aucun lien avec les expressions lambdas (ou "closures"), mais l'intérêt étant de pouvoir réellement enrichir l'API avec ces dernières. En effet les interfaces étant figées, il est assez difficile de faire évoluer l'API : le simple ajout d'une nouvelle méthode entraine de nombreuses incompatibilités.

Le rapport avec les expressions lambdas ? Ces dernières sont supposées simplifier et enrichir l'API, mais sont fortement limité par l'immuabilité des interfaces. Il fallait remettre cela en cause !

» Lire la suite!

En testant le dernier build du JDK7, j'ai découvert totalement par hasard que la classe JList était désormais paramétrée en JList<E>, comme on peut le voir dans sa javadoc temporaire. Son modèle de données ListModel a logiquement subit la même évolution.

A ma connaissance c'est la première classe de l'API Swing à intégrer les Generics en standard.

A noter toutefois qu'ils sont également déjà présent dans la nouvelle classe JLayer<V>, qui apparaitra également avec Java 7...

Petit à petit le projet Lambda suit son cours, et le brouillon des spécifications comment à bien s'étoffer.

En fin de semaine dernière, Alex Buckley a publié une nouvelle version de ce brouillon dans la mailling-list, que l'on peut retrouver ici : Project Lambda: Java Language Specification draft version 0.1.5.

S'en est suivi plusieurs discussions, dont un débat sur la syntaxe d'appel d'une expression lambda.

» Lire la suite!

En jettant un oeil aux nouveautées du JDK7, j'étais tombé sur la classe java.util.Objects qui proposait quelques méthodes utilitaires concernant les opérations de base des objets.

On y retrouve surtout des méthodes permettant de gérer les valeurs null. A première vue il n'y a rien d'extraordinaire là dedans, et je dois dire que je ne m'y étais pas vraiment attardé...

Mais aujourd'hui je suis tombé sur un billet de Joe Darcy présentant ces méthodes un peu plus en détail.

Et mine de rien cela s'annonce bien plus pratique que ce que je ne l'avais soupçonné...

» Lire la suite!

Mark Reinhold a publié au nom de Sun la première publication d'une proposition sur les expressions lambda. Mais elle se révèle pour le moment relativement succincte et s'apparente plus à une présentation sommaire des possibilités que cela offrirait qu'à une réelle proposition détaillée et précise comme cela pouvait être le cas des précédentes propositions (CICE, FCM ou BGGA).

Mais le gros problème vient du fait qu'elle ne semble pas faire l'unanimité !

En fait cette proposition fait suite à la celle de Neal Gafter et Peter von der Ahé, "Closure for Java", qui semblait faire le consensus, et que l'on imaginait facilement qu'elle servirait de base de travail aux closures de Java 7.

Or cette proposition vient d'être complétée d'une partie 0.6b qui réintègre les structures de contrôle... alors que cela ne semble pas du tout être la direction prise par la proposition de Mark Reinhold...

En fait on dirait que ces deux propositions évolue en parallèle, comme en témoigne les deux listes de diffusion : lambda-dev pour la proposition de Mark Reinhold supporté par Sun, et closures-dev pour la proposition de Neal Gafter et Peter von der Ahé (tous deux "anciens" de chez Sun, travaillant désormais respectivement chez Microsoft et Google).

Bref difficile d'y voir clair là dedans...

C'est fait, le projet Lambda est né de la volonté d'intégrer un système de closures, que l'on nommera désormais "expressions lambda".

On y retrouve donc une liste de diffusion mais surtout un prémice de la proposition : Project Lambda : Straw-Man Proposal.

On y retrouve bien sûr le détail des fonctionnalités de base dont j'ai déjà parlé plusieurs fois sur ce blog : les expressions Lambda, les types Fonction et les règles de conversion vers les types SAM.
D'autres sections restent vides, comme la transparence des exceptions ou les références de méthodes, mais sont bel et bien prévues dans la proposition (il s'agit toujours d'un document de travail).

Enfin, on dispose de plus d'information quand à l'accès aux variables, mais surtout on y découvre l'intégration des méthodes d'extensions !

Du coup j'en profite pour mettre à jour le tableau comparatif que j'avais publié dans un billet précédent :

» Lire la suite!