Présentation des nouveautés de Java 5.0 Tiger (J2SE 1.5)

Présentation des nouveautés de Java 5.0 Tiger (J2SE 1.5) par Lionel Roux

http://lroux.developpez.com/article/java/tiger/

Avec son J2SE 5.0, Sun a décidé de frapper fort en révolutionnant littéralement sa plateforme Java et en tentant de la rendre à nouveau incontournable.

Le J2SE 5.0 (nom de code Tiger) est la prochaine révision majeure de la plateforme Java. Elle est prévue pour être dévoilée en version finale pour l'automne 2004.

lire la suite...


Que pensez-vous que cette nouvelle version va apporter à vos developpement futurs ?

au sujet de Dawt:

java -Dawt.toolkit=sun.awt.motif.MToolkit -jar X11Application.jar

si j'ai un programme java, dois-je modifier quelques chose dans ce programme pour profiter de cette accélération?

tres bien l'article

Ok pour l'article, il est cool.
Toutefois, je me pose des questions concernant le "nouveau" Java. J'attends plus de Sun une JVM toujours plus rapide. L'auteur de Java (J.Goesling) a répprouvé l'utilisation des types paramétrés. Franchement, je suis d'accord avec lui, je vois pas trop ce que ça apporte étant un partisan du typage fort.
L'ellipse est par contre une bonne idée si on fait abstraction alors de la surcharge de méthode. Tout comme l'introduction du printf qui va nou permettre de passer outre la classe NumberFormat. Le tout étant qu'ils conservent la compatibilité ascendante.
Et Mr Sun, une JVM plus rapide, please !!!

@ ++

L'article est vraiment interréssant...

Citation:

---

Envoyé par GLDavid

L'auteur de Java (J.Goesling) a répprouvé l'utilisation des types paramétrés. Franchement, je suis d'accord avec lui, je vois pas trop ce que ça apporte étant un partisan du typage fort.

---

Je ne vois pas le problème si tu peux détailler ou donner un lien...

Citation:

---

Envoyé par GLDavid

L'ellipse est par contre une bonne idée si on fait abstraction alors de la surcharge de méthode.

---

Idem, peux-tu détailler car je ne comprend pas de quel surcharge tu veux parler...

Les generics ont l'air sympatiques mais aussi sources de bugs alambiqués :)
Dans l'exemple résident/client/nouvel arrivant c'est tip-top.
Mais j'imagine déjà des utilisations détournées :( voire des tentatives d'héritages multiples 8O

M'enfin, faut pas se plaindre on a échappé aux pointeurs de pointeurs :lol: :lol:

Pour la remarque sur Goesling, je l'ai lu dans le dernier Login (Juillet Aout de cette annee) ou un article traite des types parametres.

@++

Si j'ai bien compris, l'ellipse te permet de charger un nombre de parametres variables. Auparavant, si je voulais charger un nombre variable de parametres, je passais par des surcharges de methodes.

@++

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

Au fait, dans l'ellipse, le nb de paramètres est variable mais leur type est fixe. J'ai l'impression que le "précompilateur" se charge juste de la mise en tableau et de l'extraction des items.
Bref intérêt moyen, non ?

Super comme articles ...


Merci à toi

Citation:

---

Envoyé par GLDavid

Pour la remarque sur Goesling, je l'ai lu dans le dernier Login (Juillet Aout de cette annee) ou un article traite des types parametres.

---

Merci je vais essayer de le lire parce que je ne vois pas trop le problème que cela pose... au contraire...

Citation:

---

Envoyé par GLDavid

Auparavant, si je voulais charger un nombre variable de parametres, je passais par des surcharges de methodes.

---

Justement, désormais tu n'auras plus qu'une méthode...

Citation:

---

Envoyé par JefDeBourges

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

---

Ce n'est pas au niveau de la conception que c'est intérréssant mais cela permet une simplification du code...

Citation:

---

Envoyé par JefDeBourges

J'ai l'impression que le "précompilateur" se charge juste de la mise en tableau et de l'extraction des items.

---

Je ne sais pas si il s'agit du "précompilateur" ou du compilateur mais c'est ca.
L'appel de la methode est "transformé" en un appel de méthode avec un tableau en paramètre...

Citation:

---

Envoyé par JefDeBourges

Bref intérêt moyen, non ?

---

Le principal exemple est la méthode printf() comme indiqué dans l'article...

Pour moi (et surement pour tous ceux qui viennent du C) l'ajout de la méthode printf() est une très bonne nouvelle parcequ'elle permet de formater simplement des données...

PS: A noter que la méthode printf() de la sortie standard utilise la classe Formatter qui permet de faire la même chose sur d'autre éléments que des flux de sortie...

a++

Citation:

---

Envoyé par sonialem2000

au sujet de Dawt:

java -Dawt.toolkit=sun.awt.motif.MToolkit -jar X11Application.jar

si j'ai un programme java, dois-je modifier quelques chose dans ce programme pour profiter de cette accélération?

---

A priori non si ton appli est développé en utilisant sun.awt.X11.XToolkit.
J'avoue ne pas avoir testé le portage d'un awt "classique".

@+

Citation:

---

Envoyé par JefDeBourges

Les generics ont l'air sympatiques mais aussi sources de bugs alambiqués :)
Dans l'exemple résident/client/nouvel arrivant c'est tip-top.
Mais j'imagine déjà des utilisations détournées :( voire des tentatives d'héritages multiples 8O

M'enfin, faut pas se plaindre on a échappé aux pointeurs de pointeurs :lol: :lol:

---

Effectivement, des juniors vont rapidement s'emmeler les pinceaux. Justement j'ai eu une discussion avec plusieurs architectes à ce sujet. Il semblerait que le metier d'informaticien chevronné ne soit pas mort.
Ce n'est pas un concept à la portée de tout le monde. Il faut je pense une bonne approche et une bonne abstraction pour profiter des generics.


Merci
@+

Citation:

---

Envoyé par GLDavid

Si j'ai bien compris, l'ellipse te permet de charger un nombre de parametres variables. Auparavant, si je voulais charger un nombre variable de parametres, je passais par des surcharges de methodes.

@++

---

Il te permet de passer un nombre variable de parametre d'un type donnée, en l'occurence le type indiqué ds la signature. Rien ne t'empeche de passer une ellipse d'Object, ou plusieurs ellipses.

@+

Citation:

---

Envoyé par GLDavid

Pour la remarque sur Goesling, je l'ai lu dans le dernier Login (Juillet Aout de cette annee) ou un article traite des types parametres.

@++

---

les types paramétrés ne sont pas nouveaux, et le pattern utilisé existe depuis longtemps. Il a juste l'avantage d'etre intégré à l'APi standard, pour ne pas avoir à la coder. De plus, si tu as lu l'article en détails, tu t'apercois que chaque item du type est une "classe". Cela a son avantage.

Citation:

---

Envoyé par JefDeBourges

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

Au fait, dans l'ellipse, le nb de paramètres est variable mais leur type est fixe. J'ai l'impression que le "précompilateur" se charge juste de la mise en tableau et de l'extraction des items.
Bref intérêt moyen, non ?

---

Encore une fois, la plus grande partie des améliorations sont là pour simplifier le code, et donc la maintenance de celui ci.

Ca te fais des signatures simples et versatiles.

De plus ici, plus besoins de crééer et remplir " à la main" tes tableaux.

L'interet est moyen certes mais appréciable, surtout en maintenance.

Citation:

---

Envoyé par RanDomX

Citation:

---

Envoyé par sonialem2000

au sujet de Dawt:

java -Dawt.toolkit=sun.awt.motif.MToolkit -jar X11Application.jar

si j'ai un programme java, dois-je modifier quelques chose dans ce programme pour profiter de cette accélération?

---

A priori non si ton appli est développé en utilisant sun.awt.X11.XToolkit.
J'avoue ne pas avoir testé le portage d'un awt "classique".

@+

---

donc faut avoir prévu le coup dès le départ... si mon application utilise swing... je dois refaire le gui pour profiter de cette accélération

Je reviens sur l'ellipse et son (ou ses) utilité(s).
Certes, ce demander "comment pourrais-je utiliser telle ou telle fonctionnalité de l'API ?" n'est jamais très bon, mais avant que ce jdk soit en exploitation, on peut se permettre qq disgressions.

Si nous prenons l'exemple Commercial.ajouterRendezVous() dans une ch'tite appli de gestion d'agenda.
On voit bien les méthodes ajouterRendezVous(RendezVous rdv) et ajouterRendezVous(RendezVous[] tableauRdv)
La deuxième dépilant les rdv et appelant la 1ère.
La 1ère étant utilisée dans l'appli en temps réel (ou en connecté) et la 2nde étant utile lors la synchronisation entre l'agenda déconnecté
et l'agenda central.

Et là, je ne vois pas l'utilité de la méthode ajouterRendezVous(RendezVous... unOuPlusieursRdv).

Je réitère donc ma demande : Pouvez-vous me citer un exemple où ces ellipses seraient pertinentes ?

-----

Ok pour le printf() même si le besoin de formattage de résultat, au sein de classes java, me semble faible.
Mais je fais essentiellement des applis j2ee (présentation dédiée aux jsp ou aux xsl), ca doit venir de là.
Faudrait que je refasse une ch'tite appli en mode console, comme au temps où je faisais du C....

-----

Quant au "précompilateur"...
J'avais mis des guillemets car je crains que le pas n'ait pas été franchi, et qu'en fait il n'y ait qu'un compilateur.
Ce qui est à mon sens fort dommage car ca semble limiter le potentiel en méta-programmation (on ne va donc pas encore laisser tomber XDoclet !).
Mais il faut creuser plus avant les annotations avant de tirer des conclusions.
L'annotation @Overrides est quant à elle plus que bienvenue !!

A+

Citation:

---

Envoyé par JefDeBourges

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

---

Facile, l'exemple de la méthode printf en C :

printf("Ceci est un %s de chaine avec %d %s variables", exemple, 3, arguments)

Okay.... y'a des printf'maniacs :D
On pourrait parler des peek, poke , dpeek etc... 8)

Et un exemple métier, vous avez ?
Une classe qu'on code pour couvrir un besoin utilisateur, si vous préférez..

Citation:

---

Envoyé par JefDeBourges

y'a des printf'maniacs

---

Et oui !
Je n'ai jamais trop aimé le println() ni le cout du C++...

Citation:

---

Envoyé par JefDeBourges

Et un exemple métier, vous avez ?
Une classe qu'on code pour couvrir un besoin utilisateur, si vous préférez..

---

Je ne pense pas que l'ellipse couvre un besoin utilisateur...
Elle permet de simplifier légèrement la tache de du developpeurs avec un code plus clair (la création du tableau est induite)...

a++

Toujours a propos de l'ellipse...

En parcourant l'API 1.5 je me suis apercut qu'un grand nombre de méthode avec un tableau en paramètre utilisent désormais une ellipse à la place.
C'est le cas par exemple des methodes getConstructor(), getMethod() de la classe Class...

Après quelques test j'ai remarqué le comportement suivant :

La méthode de l'article:

Code:

---

1 2 3 4 5

void doSomething(Object… args) { // do something   }

---

Peut également être utilisé comme cela :

Code:

---

1 2	Object[] args = new Object[] { "arg1", "arg2", "arg3" }; doSomething ( args );

---

En fait l'ellipse possède la même signature qu'un tableau...
Si on essaye de déclarer une méthode :

Code:

---

1 2 3 4

void doSomething(Object[] args) { // do something }

---

On obtient l'erreur :

Code:

---

doSomething(java.lang.Object[]) is already defined

---

a++

Moi je ne vois pas la pertinence des import statiques.
Selon l'article de Lionel Roux, les imports statiques permettent d'éviter le préfixage des attributs ou méthodes statiques par le nom de leur classe.
Exemple:

Code:

---

1 2 3 4 5 6 7 8

import static java.lang.Math.cos public class MyClass {   private double x; MyClass(double x){ this.x=cos(x);//au lieu de this.x=Math.cos(x); }

---

}
Franchement, je ne vois pas la perte de temps ou le problème entrainé par le préfixage qu'on avait l'habitude faire au paravant. D'ailleurs je trouve que cette nouveauté va introduire au contraire des erreurs si il ya conflit entre les imports.

Salut tout le monde,

Bon voilà, je vient juste de télécharger J2SE 5.0. Avant je travaillait tjs avec l'ancien 1.4.2 :oops: .

Alors, après quelques mois de vie du nouveau né de Sun (il a bien garandit depuis à mon avis :lol: ), j'aimerai bien avoir votre avis sur les nouveautés qui ont été annoncé ? est ce qu'elle répondent bien aux attentes ? Enfin, nous partager votre avis sur J2SE 5.0...


Merci à tous.

Je n'ai pas encore pu travailler de façon professionnelle sur la version 5.0. Il faut le temps avant qu'un grand compte passe en version 5.0 -(

Ce que j'en ai vu était plutôt positif. Vive l'autoboxing ! Et, enfin, on va pouvoir utiliser

Code:

---

printf(...)

---

. En ce qui concerne les imports statiques, je connais pas, mais je trouve cela dangereux et je ne trouve pas cela génant d'ajouter les imports (surtout en utilisant Eclipse).

Citation:

---

Pour moi (et surement pour tous ceux qui viennent du C) l'ajout de la méthode printf() est une très bonne nouvelle parcequ'elle permet de formater simplement des données...

---

Justement ! Le C est quand même révolu notamment avec les langages orientés objet qui ont pris la relève, tels C++ ou... Java !!! Et oui, rappelons que Java est également un langage orienté objet, et la plupart des améliorations du langage mentionnées dans l'article sont toutes inspirées du C, qui n'en est pas un ! :( Pour l'exemple :
:!: type enum
:!: printf 8O
:!: ellipse 8O

Sans parler de l'autoboxing qui facilite la programmation aux dépends de la sûreté des programmes !! Seul ADA à ce jour (parmi les langages les + connus du moins) offre un typage fort permettant d'écrire des applications assurant une certaine sécurité. C'est d'ailleurs ce langage qui est utilisé dans le cadre d'applications concernant Ariane ou la ligne Météore. Pourtant (bien que lent) Java est très puissant et mérite sa place dans les applications importantes, notamment au niveau de la programmation distribuée... Alors pourquoi lui apporter de nouvelles limites ?? Pour aider les "informaticiens non chevronnées" ? :?

De surcroît, la nouvelle boucle for est annoncée comme étant simplifiée... Je ne m'y suis pas plongé dedans, mais à première vue (pour quelqu'un habitué au C++ du moins) elle me semble plus complexe, simplement parce que le concept change. A étudier de plus près avant de poursuivre l'argumentation...

En revanche, la généricité c'est une bonne nouvelle, que les programmeurs céplusplussiens attendaient avec impatience depuis longtemps... :idea: :D

Sérieusement, je ne sais pas mais je suis plutôt déçu (non pas de la qualité de l'article, mais des nouvelles que j'ai pu y trouver) d'être déçu, parce que Java est un langage que j'estime beaucoup alors que ce n'est pas le cas pour le C (désolé, commencer de façon intensive en C++, ça aide :wink:).

J'espère juste que je suis en train d'en faire un plat pour rien, et qu'à force d'utilisation et d'expérience, ces "améliorations" deviendront naturelles...

Citation:

---

Envoyé par fchantret

Citation:

---

Envoyé par JefDeBourges

Sans vouloir polémiquer, une méthode qui accepterait des arguments en nombre variable me semble une "erreur de conception".
Peux-tu me donner un exemple où ce besoin existe ?

---

Facile, l'exemple de la méthode printf en C :

printf("Ceci est un %s de chaine avec %d %s variables", exemple, 3, arguments)

---

Et une redirection de flux c'est pas légèrement beaucoup plus simple ?

Code:

---

cout >> "Ceci est un " >> exemple >> " de chaîne avec " >> 3 >> arguments >> " variables" >> endl;

---

Citation:

---

Envoyé par adiGuba

Je n'ai jamais trop aimé le println() ni le cout du C++...

---

Pourtant c'est beaucoup plus intuitif qu'un printf() : pas besoin de chercher comment on représente un string (%s) ni un double (%d), et tout est dans l'ordre dans lequel on le dirait oralement !! C'est presque du flux de paroles !!

En C, j'ai souvent utilisé printf (normal), mais c'est sprintf qui me manque le plus. Pour faire un formatage de string de façon simple, c'est très bien.

Code:

---

sprintf(buffer,"%20s %.4d",pszStr,iValue);

---

Pour moi, Java est un langage génial. Le C est aussi un super langage, mais pas pour faire la même chose. Je ne pense pas qu'un langage puisse être universel. Chaque langage a ses domaines de prédilections.

Salut,


Personnellement, je ne pense pas que le C soit un langage révolu... mais de toute façon ce n'est pas parce que certaines des améliorations viennent du C qu'elles sont forcément mauvaise...

Le type enum apporte une sécurisation du code, et évite ainsi de recourir à des constantes static final int peu fiable (rien n'empêche de passer une valeur 'en dur'). De plus le type enum de Java est bien un objet et n'est plus vraiment comparable au type enum du C...

Le printf() (et la classe Formatter associé) est surtout utile pour le formattage. L'opérateur + (ou << du C++) est pratique pour concaténer, mais dès que l'on souhaite utiliser un formatage spécifique cela devient plus complexe. Bien sûr cela ne concerne que la génération de fichier texte pur

L'elipse est juste une nouvelle manière de déclarer des méthodes avec un tableau en paramètre. Elle permet ainsi de simplifier l'utilisation de certaines méthodes. Je trouve d'ailleurs qu'elle n'est pas encore assez utiliser dans l'API : une petite méthode add(E...elements) aurait été bien pratique dans l'interface List, cela permettrai de remplacer le code suivant :

Code:

---

1 2 3 4 5

List<String> list = new ArrayList<String>(); list.add("chaine1"); list.add("chaine2"); list.add("chaine3"); list.add("chaine4");

---

Par :

Code:

---

1 2	List<String> list = new ArrayList<String>(); list.add("chaine1", "chaine2", "chaine3","chaine4");

---

Citation:

---

Envoyé par Original Prankster

Sans parler de l'autoboxing qui facilite la programmation aux dépends de la sûreté des programmes !!

---

Le seul problème à ma connaissance est le risque de NullPointerException lors de l'auto-unboxing (Wrapper->primaire)... mais cela ne me choque pas (le problème peut également exister sans autoboxing...)

Citation:

---

Envoyé par Original Prankster

De surcroît, la nouvelle boucle for est annoncée comme étant simplifiée...

---

En fait elle permet simplement d'itérer sur des tableaux ou sur des objets Iterable (c'est à dire qui retourne un Iterator) de la même manière, tout en initialisant les différentes valeurs...

Citation:

---

Envoyé par Original Prankster

J'espère juste que je suis en train d'en faire un plat pour rien, et qu'à force d'utilisation et d'expérience, ces "améliorations" deviendront naturelles...

---

Je pense aussi qu'il faut un temps d'adaptations...
Personnellement j'étais très sceptique quand à l'utilisation du static import, et je me surprent à l'utiliser plus souvent que je ne le pensais :D

a++

Citation:

---

Envoyé par yveslamand

Pour moi, Java est un langage génial. Le C est aussi un super langage, mais pas pour faire la même chose. Je ne pense pas qu'un langage puisse être universel. Chaque langage a ses domaines de prédilections.

---

Je pense aussi que C est un bon langage, dans le sens où il a révolutionné le monde de la programmation. Mais désormais il a évolué pour donner naissance au C++, qui est bien plus performant...

Et justement, si chaque langage a son domaine de prédilection (ce que je pense aussi), pourquoi faire ressembler un langage comme Java à un autre langage (qui plus est obsolète) ? On perdrait ainsi en spécificité... Non ?

Beaucoup de développeurs Java étaient avant des développeurs C (il suffit de regarder les catalogues des sociétés de formation. Ils ont souvent 2 cours: "Java for C programmers" et "Java for non-C programmers").

La ressemblance est au niveau des mots clés, par du langage en lui-même. int représente un entier, for = un boucle, ...

Par contre, pas d'objet en C, pas d'héritage, ...

A partir de là, donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

Citation:

---

Envoyé par yveslamand

donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

---

Le problème est bien là, d'après moi : des "méthodes identiques" :(

Citation:

---

Envoyé par adiGuba

Personnellement, je ne pense pas que le C soit un langage révolu... mais de toute façon ce n'est pas parce que certaines des améliorations viennent du C qu'elles sont forcément mauvaise...

---

En revanche, je reconnais que le langage C n'est pas mauvais. Je dis juste qu'il a permis d'inventer des langages plus évolués, et que par conséquent, lui, il l'est moins :wink:

Citation:

---

Envoyé par adiGuba

De plus le type enum de Java est bien un objet et n'est plus vraiment comparable au type enum du C...
Le printf() (et la classe Formatter associé) est surtout utile pour le formattage.
L'elipse est juste une nouvelle manière de déclarer des méthodes avec un tableau en paramètre.

---

Le type enum évidemment est un objet mais dans tous les cas reste fort pratique, pas de soucis la-dessus. En ce qui concerne le printf() et l'elipse je trouve ça moins "beau" mais ne dénigre tout de même pas leur utilité. Et oui, le soucis de la beauté du code... :lol:

Citation:

---

Envoyé par Original Prankster

Citation:

---

Envoyé par yveslamand

donner le même nom pour des méthodes identiques semblent logique. Pas besoin de réinventer la roue ...

---

Le problème est bien là, d'après moi : des "méthodes identiques"

---

Faut pas exagérer. En C, on utilise accept() pour écouter sur une socket, idem en Java.

Remarque, ce serait peut-être mieux de faire

Code:

---

1 2 3 4

new ServerSocket().addSocketListener(new SocketListener() { public void sockectConnected(SocketEvent arg0) { // ... }});

---

Pour moi, le C reste tout de même le langage bas niveau. Il reste quand même beaucoup plus rapide que le Java (à quand une JVM plus rapide ??? :roll: ) et il n'a pas son pareil pour tenir dans un petit µP 8bits.

Donc, pour moi le C est loin d'être un langage révolu, en tout cas pour le monde de l'embarqué !!!

Le JAVA c'est bien quand même :wink: , et puis c'est plus simple (pas de pointeurs... :lol: !!!

Halte aux idées reçus :

Si, il y a bien des pointeurs en Java. En revanche, c'est l'arithmétique des pointeurs qui a été supprimée.

On pourrait même rajouter : en Java il n'y a QUE des pointeurs... Mais c'est transparent à l'utilisateur :)

Non, il n'y a pas que des pointeurs. Les types primitifs t'en fait quoi? Essaie d'affecter null à un int, tu vas voir ce que le compilo va te dire!

Sans déconner... Je parlais de Java, bien sûr, par des "artefacts C" de Java.

Bonjour,
alors voilà, 2 ans après la sortie du jdk5, j'aimerais avoir vos retours sur les types génériques.
Pour ma part j'en ai marre de faire de toujours avoir à faire des cast dans le code, et je trouve que les génériques permettent d'éviter pas mal d'erreurs avant l'exécution.
Cependant je contaste que très peu d'api ont utiliser les fonctionnalités du jdk5 (pas de générique dans struts, ni dans jsf, ni dans hibernate, ni même dans spring)... Les utilisez-vous ces fameux génériques?

Citation:

---

Envoyé par sgourio

Cependant je contaste que très peu d'api ont utiliser les fonctionnalités du jdk5 (pas de générique dans struts, ni dans jsf, ni dans hibernate, ni même dans spring)... Les utilisez-vous ces fameux génériques?

---

Le monde de l'entreprise est assez "frilleuse" : elle préfère resté sur des technologie éprouvé et bien maitrisé et attendre avant de faire évoluer les choses...

Ainsi, J2SE 1.4 est encore très utilisé (de même que le 1.3 d'ailleurs).
Surtout que J2EE 1.4 fonctionne avec ces JRE, alors que Java EE 5.0 qui neccessite Java 5.0 est bien trop jeune...

Or, si les nouveautés de Java 5.0 sont très intérressante, le bytecode généré n'est pas compatible et neccessite une JVM 5.0...

Ainsi, si une API passe en Java 5.0 et utilise les nouveautés du langage, elle se "sépare" d'une grande partie de sa cible.

C'est pourquoi la plupart des API n'ont pas encore été migré : elle offre une meilleure compatibilité avec les JVM plus anciennes...

Il faudra attendre que Java 5.0 devienne la "norme" en entreprise pour voir les API externe migrer petit à petit...

Surtout que cette migration a un coût, et que la maintenance de deux versions l'est encore plus ;)

a++