août
2011
Un article de adiGuba
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
Java SE 7
Comme convenu, Java SE 7 se limitera à trois principales JSRs :
- JSR 203: More New I/O APIs for the Java Platform (« NIO.2″)
- API FileSystem permettant un accès complet au système de fichier (en remplacement de la classe
Filetrès limité) (Lire : NIO.2 : Accès au système de fichier dans Java 7 - API d’E/S asynchrone pour les fichiers et les sockets.
- Finalisation des fonctionnalités de la JSR 51 sur les SocketChannel (binding, configuration et multicast).
- API FileSystem permettant un accès complet au système de fichier (en remplacement de la classe
- JSR 292: Supporting Dynamically Typed Languages on the Java Platform
- Support de l’instruction invokedynamic afin de supporter des langages dynamiques directement au niveau du bytecode.
- API java.dyn permettant d’utiliser cela en Java (InvokeDynamic et MethodHandle).
- JSR 334: Small Enhancements to the Java Programming Language (OpenJDK Project Coin)
- Switch sur les chaines de caractères (
String) - Amélioration des valeurs numériques (valeurs en binaires et underscores)
- Multi-catch et rethrow évolué (Lire : Gestion des exceptions améliorée (multi-catch et rethrow))
- Amélioration du « Type Inference » des Generics, et syntaxe en losange (Diamond syntax)
- Gestion automatique des ressources (ARM aka try-with-resources) (Lire : Java 7 et les try-with-resources (ARM block))
- Simplified Varargs Method Invocation
Lire : Projet Coin : Les modifications du langage pour Java 7 (note : le support syntaxique des collections a été reporté pour Java 8).
- Switch sur les chaines de caractères (
Tout en incluant des changements de maintenance des JSRs existantes, et un certain nombre de « petites » modifications :
- Thread-safe concurrent class loaders
- Unicode 6.0
- Enhanced locale support (IETF BCP 47 and UTR 35)
- TLS 1.2
- Elliptic-curve cryptography
- JDBC 4.1
- Standardisation des APIs de Java 6u10 (Translucent and shaped windows, Heavyweight/lightweight component mixing, Swing Nimbus look-and-feel, Swing JLayer component)
Java SE 8
Coté Java 8 c’est déjà plus interressant car on découvre pour la première fois la proposition des JSRs qui le composera :
- JSR 308: Annotations on Java Types
- Généralisation de l’utilisation des annotations sur tous les types, et non plus uniquement sur les classes/méthodes/attributs/variables.
- JSR 310: Date and Time API
- Une nouvelle API en remplacement de l’obsolète classe
Date, qui intègrera des notions totalement absente de l’API actuelle (instant, durée, intervalles, etc.)
- Une nouvelle API en remplacement de l’obsolète classe
- JSR ???: More Small Enhancements to the Java Programming Language (OpenJDK Project Coin)
- On peut penser que le support syntaxique des collections fera partie du lot.
- Autre chose ? (la conférence de Devoxx pourrait nous en apprendre plus)
- JSR 335: Lambda Expressions for the Java Programming Language (OpenJDK Project Lambda)
- Les expressions lambdas (équivalent d’une méthode anonyme).
- Conversion vers les types SAM
- Method references
- Exception transparency
- Public Defenders Methods (Lire : Evolution des interfaces avec les « public defenders methods »)
- JSR ???: Java Platform Module System
Dommage collatéral
On peut noter également le report indéterminé de trois JSRs :
- JSR 260: Javadoc Tag Technology Update.
- Rien d’étonnant car cette vielle JSR avait déjà été reportée. A mon avis elle sera purement abondonné.
- JSR 295: Beans Binding
- Il est trop tôt pour cela, car c’est typiquement le genre d’API qui gagnera en qualité avec l’utilisation des expressions Lambda.
De plus pendant les conférences de Devoxx il a été question d’intégrer à Java un vrai système de property. Si binding il y a il devrait être basé là dessus !
Bref il est préférable d’attendre le JDK 8 au minimum !
- Il est trop tôt pour cela, car c’est typiquement le genre d’API qui gagnera en qualité avec l’utilisation des expressions Lambda.
- JSR 296: Swing Application Framework
- Aucune idée… et vu l’évolution lente du JDK et de Swing je ne sais même pas si ce serait une bonne idée.
A titre personnel, et au risque d’en faire hurler certain, j’opterais pour une refonte totale de la couche UI.
- Aucune idée… et vu l’évolution lente du JDK et de Swing je ne sais même pas si ce serait une bonne idée.
Enfin une date ?
En pleine conférence Devoxx, il semblerait que les dates commencent à se confirmer.
Le JDK7 devrait être disponible en juillet 2010, tandis que le JDK8 arrivera fin 2012 (en même temps que la fin du monde selon les Mayas – il y a peut-être une relation de cause à effet !)
12 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- [ fuite ] memoire
- jre 1.5, tomcat 6.0 et multi processeurs
- Possibilité d'accéder au type générique en runtime
- Définition exacte de @Override
- Difference de performances Unix/Windows d'un programme?
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Classes, méthodes private
- Recuperation du nom des parametres
[…] Devoxx 2010, Divers Enfin des JSRs pour Java 7 & 8 par adiGuba (17/11/2010 11:38) Les JSRs sont des documents primordiaux du Java Community Process, […]
Moi qui n’espérait même pas une réponse, il aura fallu moins d’une demi-heure.
Je m’en vais commenter les billets en question
Surtout que les sujets qui m’intéressent le plus sont :
PS completement HS : Il faudrait revoir la gestion du « Auto-BR » qui n’est pas compatible avec le formatage manuel et certaines balises (ul par exemple -_-‘). D’ailleurs pourquoi ne pas avoir adopté une syntaxe Wiki-like ?
Concernant les évolutions du langage de Java 7, tu peux te retourner vers les billets indiqués dans cette section, qui sont globalement à jours à quelques détails près (je viens d’éditer afin d’y ajouter quelques remarques sur les changements les plus important) :
Concernant l’invocation dynamique et les APIs par contre cela a beaucoup évolué même si l’esprit reste là. Dans ce cas le mieux étant de se référer à la javadoc (même si elle n’est pas encore finalisé) : Java 7 API
Enfin concernant Java 8 ça bouge encore beaucoup, et sauf erreur rien n’a encore été fixé… mais il est encore tôt
a++
Je viens de découvrir ce billet et les propositions pour Java 7 (oui je suis à la traîne, disons que j’ai suivi le titre des fonctionnalités mais à en quoi elle consistait exactement)
Je voulais savoir s’il y avait encore des discussions actives sur ce sujet ? Je suis bien conscient que l’heure n’est plus au débat (encore qu’on peut « espérer » des évolutions sur ces nouveautés pour Java 8).
Ma principale question est-ce que la syntaxe adoptée est celle présentée dans les différents billets ? Ou dois-je prendre mon courage à deux mains pour lire les JSRs ?
« Apache n’aura jamais la licence TCK. »
Je prie très fort pour l’arrivée de vraies properties! En fait je prie pour ça depuis le premier jour ou j’ai découvert, les Beans.
Je pense qu’il y a beaucoup de bon dans swing, malheureusement, il manque de simplicité et bien l’utiliser est plus dur qu’il n’y parait, notamment à cause des problème d’EDT, et le mécanisme de listener trop verbeux, certains composants un peu trop complexe, d’autre qui brillent par leur absence…
Je pense également qu’en reprenant le tout en faisant quelque-chose qui utilise les amélioration du langages actuelles, et celles à venir, il y a moyen de faire quelque-chose de beaucoup plus facile à utiliser.
Malheureusement Oracle va clairement s’orienter vers JavaFX qui ne sera probablement jamais libéré, et qui personnellement ne me tente pas du tout pour faire des applications classiques.
Et pour refondre la partie UI, je te seconde totalement. Il semblerait vraiment que le mix AWT et Swing soit un ensemble bien dur à maintenir et faire évoluer (et indirectement une des raisons pour laquelle Apple a décidé de jeter l’éponge pour le portage maison de la JVM).
Reste à voir ce qu’ils prévoient de faire ensuite de JavaFX, parce qu’actuellement il me semble comme un bon candidat de remplacement d’AWT/Swing, vu notamment qu’il y aura de quoi faire des formulaires.
Au demeurant, Swing a beaucoup de bon aussi: il ne s’agit pas de jeter à l’eau les principes derrières.
Changer le LnF par défaut risquerait de poser bien trop de problème de compatibilité.
Pour info avec Java 5 ce n’était pas vraiment un changement de LnF mais simplement de « thème ». Tous les composants restait identique en taille au pixel près…
Pour Apple c’est sûr que c’est une bonne nouvelle. Déjà cela permettra de réintégrer toutes les spécificités de la JVM Apple, mais surtout cela veut dire qu’on continuera à avoir du Java sur Mac (sans avoir 2 ans de retard !)
a++
Et oui. Enfin.
Autre chose. Le look and feel Nimbus fera partie de Java se 7. Mais ne sera pas celui qui est actif par defaut. Il faudra indiquer explicitement qu’on veut ce look & feel.
Oracle etait egalement tres fier d’annoncer que non seulement IBM supportait OpenJDK. Mais egalement Apple.
En fait, ils sont tres tres content qu’Apple supporte OpenJDK.
La « feature complete » dans 1 mois ! Enfin !
a++
Je confirme que cela fut la belle annonce surprise de la keynote de ce matin a Devoxx.
Voici le planning annonce pour le JDK 7 :
16/12/2010 Feature Complete
12/04/2011 P1-P3 bugs only
2011/04/28 API/Interface changes Showstopper only
2011/05/11 All targeted bugs adressed. Preliere Release Candidate
2011/05/18 Bug fixes. Uniquement showstopper
2011/06/08 Final Test cycle starts
2011/07/28 General Availability
Si ils pouvaient ajouter les properties au jdk8 ça serait vraiment cool!