Discussion :

[christopheJ]

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 ?

[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?

[dk]

tres bien l'article

[GLDavid]

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 !!!

@ ++

[adiGuba]

L'article est vraiment interréssant...

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...

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...

[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

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

[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.

@++

[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.

@++

[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 ?

[cameleon2002]

Super comme articles ...


Merci à toi

[adiGuba]

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...

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...

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...

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...

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++

[RanDomX]

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".

@+

[RanDomX]

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

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

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
@+

[RanDomX]

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.

@+

[RanDomX]

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.

[RanDomX]

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.

[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

[JefDeBourges]

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+

[fchantret]

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)

[JefDeBourges]

Okay.... y'a des printf'maniacs
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..