|
Publicité ' | ||||||||||||||||||||||||
|
|
#1 |
|
Invité régulier
![]() |
Bonjour,
La version 1.5 du J2SE est prévue pour la fin 2003. Sur le site de Sun, vous pourrez trouver une interview intéressante d'un responsable de développement, qui parles des principales améliorations : http://java.sun.com/features/2003/05/bloch_qa.html Quelques améliorations sont d'ores-et-déjà alléchantes : la simplification des boucles (un "for" tout rikiki au lieu d'iterator), ou encore l'autoboxing pour éviter de se pourrir la vie avec les types primitifs dans les collections. Par contre, même si ça s'annonce très pratique au final (plus de cast), l'utilisation des "generic" risque d'être un peu fastidieuse au début... |
|
|
00
|
|
|
#2 |
|
Membre éprouvé
![]() Inscription : avril 2002 Messages : 405 ![]() |
Tout ça m'a l'air très sympa!
Je me réjouis principalement de voir à l'oeuvre les "generics" (qui ressemblent aux <templates> de c++) et les "type-safe enumerations". J'espère juste que toutes ces améliorations ne vont pas grever les performances de Java... |
|
|
00
|
|
|
#3 |
|
Nouveau Membre du Club
![]() |
lee Generics seront sans aucun doute un apport considerable au langage... Pour ma part l'absence de genericite est le plus grand manque du langage...
L'operateur ':' (in) est un peu detasbilisant... Mais ca a l'air tres puissant pour la gestion des collections. Les enumerations egalement seront un gros progres, je ne me suis pas encore penche sur ces enumerations, mais ca a l'air bien plus puissant et sur que les enum C. J'espere qu'ils pourront aussi ameliorer les performances generales de la JVM ... J'ai hate de voir ;-) |
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() ![]() Inscription : mars 2003 Messages : 579 ![]() |
idem pour les generics.
Le mecanisme des templates c'est tellement important... Vivement fin 2003. |
|
|
00
|
|
|
#5 |
|
Nouveau Membre du Club
![]() |
C'est genial, j'avais pas vu, on peut telecharger les specifications preleminaires :
http://jcp.org/aboutJava/communitypr...review/jsr014/ Ainsi qu'une pre-release du compilateur... http://developer.java.sun.com/develo...ding_generics/ |
|
|
00
|
|
|
#6 |
|
Inactif
Inscription : avril 2002 Messages : 51 ![]() |
Ca a l'air prometteur, tout ça. Toutefois, comme l'a dit quelqu'un plus haut, amelirer les performances de la JVM est egalement un sujet très important, surtout dans le contexte actuel de mise en concurence des environnements.
|
|
|
00
|
|
|
#7 |
|
Futur Membre du Club
![]() Inscription : avril 2002 Messages : 45 ![]() |
Moi je suis bien content de l'arrivee des enumerations. Fini de devoir creer une classe pour avoir une simple enumeration. Ca va faciliter pas mal la vie.
|
|
|
00
|
|
|
#8 |
|
Membre du Club
![]() Inscription : mai 2003 Messages : 58 ![]() |
Je suis un peu perplexe aussi sur le coup du for (... : ...) J'aurais préféré un truc du genre foreach ... in ... Mais comme ils disent, ça risque de mettrent pas mal de programmes dans une incompatibilité totale vu que le mot-clé in est nouveau . D'ailleurs, je viens de m'apercevoir que moi-même dans mes programmes, j'utilise régulièrement in comme variable
|
|
|
00
|
|
|
#9 |
|
Futur Membre du Club
![]() |
La compatibilité fut en effet mon premier réflexe lorsque j'ai lu l'article.
Que se passera-t-il pour ceux qui ont développer des milliers de lignes de code dans les versions précédente en utilisant par exemple "in"? A mon avis, ils vont procéder de la même manière que pour les méthodes DEPRECATED en les autorisant encore mais en flashant un Warning deprecated si vous utilisez l'option à la compilation. Ils n'auront pas le choix, sinon, beaucoup vont devoir rester à la version précédente au risque de devoir replonger dans des dizaines de pages de codes, voir plus! Le For "each...in" est extrêmement pratique lorsque vous voulez traiter que les éléments d'un type particulier dans une collection comportant des éléments de différentes natures (String et Integer par exemple). Rien ne vous oblige à les utiliser. Pour les Generics, c'est une façon de simplifier en mettant le casting explicit à un niveau plus élevé que les objets eux-mêmes à savoir le container et non le contenu (Collection et non les objets contenu). Il n'est pas spécifier si ce casting explicit est obligatoire ou pas. Si c'est obligatoire, le problème de compatibilité va devenir encore plus important La partie autoboxing m'échappe un peu... ainsi que l'histoire sur les Meta Quelqu'un pourrait expliquer ces 2 points please? |
|
|
00
|
|
|
#10 |
|
Membre éclairé
![]() ![]() Inscription : mars 2002 Messages : 127 ![]() |
Tu as certainement mal lu, il n'y a pas de each..in, il y a un ":"
Donc je ne vois pas de probleme d'incompatibilite. Ils n'ont ajoute aucun keyword (contrairement a la derniere fois avec assert) autoboxing, pour ce que j'ai compris, tu pourras utiliser Integer ou int plus ou moins de la meme facon, c'est a dire mettre un 1 dans une hashtable par exemple, ou additioner un Integer avec un int. Le meta, c'est un peu comme javadoc qui genere de la doc, sauf que la ca genererait du code. Si tu connais xdoclet, ca ferait un peu la meme chose, sauf que ca serait standard. Pour les generics, le principe, c'est que justement il n'y a plus besoin de casting si tu utilise Generics (voir exemple). Tu peux toujours utiliser l'ancienne version des collections bien sur, et alors tu seras force de faire un cast a chaque fois. Generic t'economise un cast, et t'evite de nombreux problemes de ClassCastException puisque tu connais le type de l'objet a la compilation. C'est vraiment les templates C++, qui manquaient jusque la.
__________________
Christophe Ludet Testez vos connaissances Java - http://knotty.developpez.com Donner des ailes a votre application (J2EE patterns) - http://knotty.developpez.com/j2ee |
|
|
00
|
|
|
#11 | |
|
Futur Membre du Club
![]() |
Je sais que c'est un ":" mais pas un "each...in" mais il a exactement le même effet.
Je parler d'un problème de compatibilité sur ce que hlr venait de dire: Citation:
Je crois déjà que le premier test sera la recompilation de nos programmes existant avec la mouture 1.5. Existe-t-il des logiciels de "benchmark" pour les programmes java? (Tu le run et tu as des stat sur la vitesse - instruction/seconde - la taille en mémoire, etc... ) |
|
|
|
00
|
|
|
#12 |
|
Membre éprouvé
![]() Inscription : mars 2002 Messages : 620 ![]() |
question béotienne : un développeur utilisant les finesses du 1.5
rend il obligatoire qu'un poste client utilisant son appli d'être équipé de la version 1.5 du run time ou la version antérieure suffit-elle ? |
|
|
00
|
|
|
#13 | |
|
Membre éclairé
![]() ![]() Inscription : mai 2002 Messages : 296 ![]() |
Citation:
|
|
|
|
00
|
|
|
#14 |
|
Membre éclairé
![]() Inscription : mars 2002 Messages : 395 ![]() |
C'est nouveau ça. Parceque mes applis compilées en 1.4 elles passent en 1.3 sans problèmes du moment que je n'utilise pas les nouvelles api.
__________________
Creapage.net/blog |
|
|
00
|
|
|
#15 | |||
|
Invité de passage
![]() Inscription : novembre 2003 Messages : 1 ![]() |
Citation:
Code :
compiler en 1.4 le code marche et s'excute sur un jre 1.4 et pas 1.3 ! La raison est simple append(Object o) existe en 1.3 donc sb est caste en Object append(StringBuffer sb) n'existe que depuis 1.4. Donc compiler, c'est cette derniere methode qui est appelee et plus append(Object o). S. [ Modéré par avtonio ] -> Balises BBCode rajoutées. -> Merci de respecter les règles du forum Java. |
|||
|
|
00
|
|
|
#16 |
|
Invité de passage
![]() Inscription : décembre 2003 Messages : 8 ![]() |
voyons c est vrai que les generics c est super importnat
mais bon quand meme java a ete conçu a la base dans le but de simplifier la vie des utilisateurs du c++ langage de presque plus haut niveau avec des impleations deja toutes faites pour ts les types tesl que les collections les set ... alors bon en rajoutant les generics j espere que les gens ne se casseront pas la tete a essayer de tout reimplementer eux memes, java marche si bien !! |
|
|
00
|
|
|
#17 | ||||
|
Invité de passage
![]() Inscription : juin 2002 Messages : 6 ![]() |
Salut, a tous !
J'ai été suffisament curieux pour aller tester la version beta. Je peux vous rassurer : un code compatible avec la version 1.4 est compilé sans probleme avec la version 1.5 a quelques deprecated pres, comme pour chaque changement de version. Sinon le laf par defaut de java n'est plus le meme, il se nomme ocean et parait tres bien fait, et beaucoup plus jolie que le laf "metal", il a des effets un peu à la windows XP, j'espere qu'on pourra toujours aussi facilement creer des themes. Pour ce qui est des nouveautés au niveau de la syntaxe comme les template, je n'ai pas réussi a compilé Code :
[EDIT] J'ai trouvé pour compiler, il faut faire : javac -Xlint -source 1.5 *.java Et a ce moment, il y a énormément de warning, mais ça passe. Sinon voila un code qui illustre beaucoup de nouveauté, ce code est fourni par SUN avec le "adding_generics-2_2-ea", je l'ai quand meme légèrement modifier pour qu'il soit compatible avec le sdk1.5 : Code :
|
||||
|
|
00
|
|
|
#18 |
|
Débutant
Inscription : juin 2002 Messages : 32 ![]() |
Ah, je suis bien content qu'il aient changé le Look And Feel "Metal", c'etait vraiment pas beau ce gris avant
|
|
|
00
|
|
|
#19 |
|
Invité régulier
![]() Inscription : février 2004 Messages : 27 ![]() |
Bonjour,
quelqu'un connaitrait-il la date de la version finale du jdk 1.5? |
|
|
00
|
|
|
#20 | |
|
Membre du Club
![]() Inscription : mai 2003 Messages : 58 ![]() |
Citation:
Après avoir regardé dans ma boule de cristal, je dirais dans 6 mois |
|
|
|
00
|
Copyright © 2000-2013 - www.developpez.com