août
2006
La JSR 270, dont l’objectif est de définir ce que comportera Java SE 6, vient de passer en « Public Review ». Il est ainsi possible de télécharger le « Release Content » qui offre la possibilité à tout un chacun de donner des commentaires sur cette ébauche (et ce jusqu’au 26 septembre prochain).
Il n’y a rien de vraiment nouveau ou inattendus puisqu’il y a déjà eu plusieurs versions de ce document, si ce n’est toutefois l’ajout d’une politique de suppression de fonctionnalité (pour la première fois dans l’histoire de Java).
Quoi qu’il en soit cela reste une bonne occasion de découvrir les principales nouveautés de la prochaine version de Java…
Que contiendra donc Java SE 6 ?
On y retrouve tout d’abord la liste des JSR qui ont été acceptées pour l’ajout dans l’API standard :
- JSR 105 : XML Digital-Signature APIs
- JSR 173 : Streaming API for XML (StAX)
- JSR 181 : Web-Services Metadata
- JSR 199 : Java Compiler API
- JSR 202 : Java Class-File Specification Update
- JSR 221 : JDBC 4.0
- JSR 222 : Java Architecture for XML Binding (JAXB) 2.0
- JSR 223 : Scripting for the Java Platform
- JSR 224 : Java API for XML-Based Web Services (JAX-WS) 2.0
- JSR 250 : Common Annotations
- JSR 269 : Pluggable Annotation-Processing API
Enfin, contrairement à ce qui était initialement prévu, ces trois JSR et ces deux fonctionnalités ne seront pas intégrées :
- JSR 260 : Javadoc Tag Update, car aucun consensus n’a pu être atteint sur plusieurs points critiques. Cette JSR devrait être reportée dans Java SE 7…
- JSR 268 : Java Smart-Card I/O API, car elle ne représentait pas un intérêt suffisant pour être intégrée en standard. Elle sera disponible indépendamment.
- La prochaine version de JAXP n’a pas été inclut car la JSR n’a pas été soumisse à l’approbation.
- L’accès aux noms des paramètres de méthode via la réflection, ce qui devrait être réétudié pour Java SE 7.
- L’internationalisation des URI, qui avait été intégré dans le build 55, mais qui a ensuite été supprimé car ils posaient de nombreux problèmes de compatibilité.
S’ajoute à cela des changements mineures qui ont été apporté à des JSR de Java 5.0 :
- JSR 3 : Java Management Extensions (JMX)
- JSR 160 : Java Management Extensions (JMX) Remote API 1.0
- JSR 206 : Java API for XML Processing 1.4
A noter également l’intégration du GroupLayout, le LayoutManager utilisé par Matisse (le générateur d’interface graphique de NetBeans), suite à une forte demande…
La fin de la compatibilité « totale » ?
Mais la grande nouveauté vient de l’apparition d’une politique de suppression de fonctionnalité. En effet, avec le temps l’API est de plus en plus importante, car au cours du temps, de nombreuses APIs ont été ajoutées mais aucune n’a jamais été supprimée. Or certaine de ces APIs sont désormais peu utilisé.
Un processus de suppression fera donc désormais partie de l’évolution du langage et de son API : à chaque JSR concernant une spécification de Java, la suppressions de fonctionnalités pourra être proposée (on parle ici de fonctionnalités au sens large, c’est à dire des packages ou des sous-systèmes complets, et non pas des classes ou méthodes). Toutefois, elle ne pourra être réellement effective que dans la version suivante de Java.
Ainsi, c’est le package javax.sound.midi qui pourrait être le premier à être supprimé. En effet, ce dernier n’est pas vraiment très utilisé par la majeur partie des applications, alors que son implémentation est assez coûteuse en espace disque (1/2 Mo). Il a donc été proposé en suppression (d’autres package tel que ceux relatif à Corba ont également été proposé à la suppression, mais cela n’a pas aboutit à un consensus).
Qu’est-ce que cela veut dire ?
- Le package sera-t-il supprimé de Java SE 6 ?
NON : ce n’est qu’une proposition pour la version suivante de Java (Java SE 7 en l’occurence).
- Le package sera-t-il supprimé de Java SE 7 ?
Pas forcément. Ce sera au groupe d’étude de Java SE 7 d’accepter ou non la suppression de ce package.
Et même si la suppression est officiel, il pourra toujours être distribué avec le JRE (selon le libre arbitre du revendeur), ou être distribué séparément.
Toutefois, Java SE 7 devrait intégré un système de module pour télécharger des ressources dynamiquement à l’exécution. Il y a ainsi de forte chance que les fonctionnalités supprimées soient toujours disponible via un téléchargement automatiquement en cas de besoin lors de l’exécution du programme (ce qui pourrait augmenter le nombre de package « supprimé » de l’API standard).
Bref, c’est un mini-tournant dans le monde de Java, où un « petit » coup vient d’être donné à sa fameuse compatibilité ascendante…
Source : Java SE 6 Release Contents (JSR 270): Public Review et Removing features from the Java SE platform par Mark Reinhold.
4 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- [ fuite ] memoire
- Définition exacte de @Override
- Difference de performances Unix/Windows d'un programme?
- Classes, méthodes private
- Possibilité d'accéder au type générique en runtime
- jre 1.5, tomcat 6.0 et multi processeurs
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Recuperation du nom des parametres
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
>> Seulement, si on veut le continuer en JDK1.7, il faudra changer les import dans le .java et inclure un jar supplémentaire au projet.
Si tu as obligé de modifier ton code pour le faire marcher ce n’est plus compatible.
Mais je ne pense pas que le nom des packages changent.
Seulement, si le package javax.sound.midi est retiré du JDK 1.7, une application qui l’utilise ne sera plus garantit de fonctionner sur ces JVM :
* Soit le package sera quand même inclut par le revendeur et alors cela marchera.
* Soit le package ne sera pas inclut par défaut mais la JVM pourrait demander à l’utilisateur s’il accepte de télécharge le package pour continuer à utiliser l’application.
* Soit le package ne sera pas inclut du tout et tu devra l’ajouter comme une librairie externe.
Je ne dis pas que le programme ne pourra plus marcher, mais que les contraintes pourront être différentes.
Maintenant c’est sûr qu’il faut relativiser et voir comment cela sera gérer dans le JDK 7. Et en particulier en ce qui concerne la JSR 277 « Java Module System » !
a++
Je ne vois pas où il y aura un coup à la compatibilité ascendante :$
Du code fait avec javax.sound.midi en JDK 1.6 tournera toujours en 1.7.
Seulement, si on veut le continuer en JDK1.7, il faudra changer les import dans le .java et inclure un jar supplémentaire au projet.
Bref, je ne vois pas où est le problème de compatibilité ascendante, ou alors (plus probable, snif) je rate quelque chose ?
Merci d’avance
>> En enlevant des fonctionnalités aux api standards, est-ce que cela va améliorer les performances de java?
Non : l’objectif est surtout de limité la taille du JRE et ainsi faciliter son téléchargement.
Quand aux performances, on ne peut pas vraiment dire que les JVM actuelles souffrent de gros problèmes…
a++
En enlevant des fonctionnalités aux api standards, est-ce que cela va améliorer les performances de java?