adiGuba:Blog

Un article de adiGuba    4 Commentaires

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.