Reprise du message précédent :

 
tu reproches quoi a la genericité et a la surcharge ??

VB 6 était compatible avec toutes les versions antérieures
C'est vrai que VB .NET nécessite la réécriture de tout programme fait en VB6 (et qu'on me parle pas de leur outil de migration totalement pourri et inutilisable), mais vu la qualité de VB .NET par rapport à VB6, ça vaut bien une totale refonte du langage je pense.
 

Viens donc à Bordeaux, tu repartiras avec une cave bien remplie et ce sera moi ton pote quand tu rentreras

On peut assimiler ça à des pointeurs de fonctions, mais propres et typés (pas comme le C/C++)

 
Je dirais plutot un système de typage permettant de garantir la signature d'une méthode passée en paramètre.

J'ai édité mon post avant ta réponse

faut pas oublier que ce n'est pas juste sun qui décide ce qu'il y aura dans les futures version de java...
 
ils me semble que sun était contre la généricité mais les contructeurs la voulaient...
 
de plus je pense pas que java soit en retard, java est déjà fort bien implanté tant en industrie qu'au niveau éducation...
d'ailleurs plusieurs personne que je connais au usa ne voit même pas le c++ à l'université...
 
dans ma formation d'ingénieur je n'ai eu 1 cours de c++ et dans mon  dec qu'un cours aussi
c'est java à fond... tout simplement parce que les entreprises veulent des programmeurs java
 
et ici l'éducation est vraiment pas prète à changé pour .net

je ne reproche rien à la généricité.
 
C'est juste que le Java c'est un langage qui a la base est super simple y ajouter des fonctionnalités comme la généricité et la surcharge des opérateur tent à le complexifier.
 
la surcharge des opérateur je trouve que ca ne sert réellement que dans de très rare cas ... trop rares pour motiver un changement aussi important en Java.
 
de plus, je trouve que ca va pas de le sens de l'OO qui à la base est un échange de message entre objets ...

bha des interfaces quoi ...

Harko, pour répondre à ta question, oui tu trolles. On te demande ce que tu penses de Java 1.5, pas de faire un énième comparatif à la mords-moi-le-noeud Java/C#.
Franchement, ce genre de comparatif a déjà été revu 5000 fois partout sur le Net et le topic sur les langages est là pour ça. Ce genre de post de la part d'un modo ça fait désordre, chu désolé

d'après ce qu'à dit le mec dans la conf sur la généricité, ils planchent sur ce truc depuis 5 ans ... et c'étaitun gars de sun

Certes, mais mon post n'avait pas vocation à être un tel comparatif. Ce que je trouvais curieux, c'est que tout le monde soit ébahi devant des fonctionnalités qui existent déjà sur d'autres langages depuis un petit moment. Ce qui explique que, contrairement à la mouvance générale, je ne sois pas aussi enthousiaste, c'est tout

je suis pas ébahi ! je trouve juste sympa qu'ils ajoutent des features intéressantes ...

Bon je dis plus rien

rho l'aut !! faut pas le prendre comme ca

Bin tu sais, c'est des specs sur des fonctionnalités dont certaines sont attendues depuis longtemps ou parce que leur arrivée va faciliter certaines implémentations. En plus, c'est seulement des specs, pas l'implémentation en elle-même. Donc forcément, les gens qui bossent en Java voient arriver le truc d'un bon oeil (j'y reviens par la suite). Maintenant, Sun va pas dire "oah on a rajouté quelques fonctionnalités sympas mais aussi beaucoup de bugs" ou un truc du style. Donc bien sûr, sur le papier, ça fait plaisir à lire, faut pas t'attendre à du "non c'est nul, ça va tout casser" puisqu'au contraire ce sont des fonctionnalités souvent réclamées par les développeurs.
 
Mon point de vue sur la 1.5 : ça va être très intéressant, y a plein de choses qui paraissent bien. Par contre, sur les generics, bien que l'idée soit bonne je trouve l'implémentation un brin pénible (voire moche) mais bon, j'm'y ferai. Pareil, le foreach est super utile mais assez pourri à relire (perso j'aurai préféré un mot-clé comme in plutôt que le bête : ).
 
Vala. Un lien utile pour les gens que la 1.5 intéresse mais qui aimeraient une vue globale et un peu plus vulgarisée que des specs brut de fonderie : http://java.sun.com/features/2003/05/bloch_qa.html

 
Oui, c'est un des premier JSR du JCP (le 14). Là bas, le JSR a été lancé le 17 mais 1999 (sachant que lorsque tu lance un JSR, il y a déjà de la pré-étude en amont).

 
et attend, t'as pas encore vu comment écrire une classe générique !
 
pour la syntaxe, ils ont pris la même que celle du C++ ... moi aussi je la trouve pas top, mais je crois que c'est juste parce qu'on y est pas habitué ...
 

bha ca par contre ca va ... je trouve bien compréhensible !
En plus, ils voulaient éviter d'ajouter des mots clefs pare que ca entraine des incompatibilités avec le source existant. Genre in, il est souvent utilisé (ex : System.in)

Ba moi c'est le genre de truc auquel je suis complètement imperméable J'préfère un bon mot-clef plutôt qu'un opérateur, c'est plus lisible pour moi.

Ba : c'est utilisé aussi, genre l'opérateur ternaire (que je hais pour la raison de lisibilité sus-invoquée) plouf : plif ? plof. A moins qu'il n'y ait une liaison de cause à effet quelque part, le signe : a double utilité Alors que in, p'têt qu'il est utilisé en tant que champ statique de System, mais franchement ça a aucun rapport avec un opérateur ou mot-clé.

 
Comment on fait ?
Es-ce que l'on peut avoir des paramètre de template par defaut ?
Peut-on contraindre la généricité (n'autoriser que les classes qui implémentent certaines interfaces par exemple) ?
Es-t'on limité aux classes/interfaces ou peut-on utiliser les types primitifs ?

c'est pas ca ! c'est juste que les mots clefs tu peux pas les utiliser pour nommer des variables, sinon le compilo comprend plus rien => si tu ajoutes un mots clef à un langage déjà existant, tu ne pourras plus compiler tous les sources qui se servaient de ce mot clef. Donc, dans le cas de "in" c'est très grave !

 
Chose qui s'est passé avec le mot clef new lors du passage C=>C++, puisque dans beaucoup de sources, new était un nom de variable courant style nouvel élément.

Ahhhhhh oké... j'comprends mieux Effectivement, du coup c'est assez critique

plouf ? plif : plof
 
 
d'ailleurs c'est assez lisible comme ça, je trouve
 
a==b ? c=2 : d=4
 
est-ce que a est egal à b ? alors c=2 ... sinon d=4

Ah ba en plus j'me plante Ca en dit long sur mon utilisation intensive de ce truc
Nan mais j'comprends qu'il y ait des gens pour qui ça paraisse clair, mais moi pas

 
Pas assez fnu je trouve, et pas de valeur ajoutée par rapport àç un if/then/else (qui est plus évolutif à mon sens).
 
res = a<0?-a:a;

ca devrait ressembler à ca : (E c'est le nom donné au type généric)

 

 

 
pour la dernière syntaxe, ils n'en sont pas encore sûr ...
 

Je sais pas ... j'imagine que oui et que ce sera la classe de base de la généricité (celle dont tu parles dans la question suivante  
 

oui. Je l'avais vu dans aucun exemple => je l'ai demandé au gars qui fesait la conf à la fin de la session et il m'a confirmé que oui
 
ca devrait se faire comme ca :  

oui t'es limité aux objets
 
toutes les modifs de la JDK 1.5 ne remettent pas en cause la JVM : c'est juste du boulot en plus pour le compilo. Pour apporter la généricité aux types primitifs, il y aurait eu une gestion de la mémoire différente. Genre si tu fais une ArrayList<double>, c'est pas la même place mémoire pour stocker un pointeur et un double, etc ... et ca posait tout un tas d'autres problèmes => ils ne l'ont pas fait.
remarque : avec l'autoboxing, tu peux t'en sortir assez facilement ...

et bravo pour les screenshots de code (Aaaah si j'avais eu un APN pendant mes études, ça m'aurait évité de prendre des notes)

reviendrai lire + tard  

Pour ma part, il y avait longtemps que j'attendais les génériques. J'ai découvert ce mécanisme avec Ada il y a 12 ans, et je trouve que c'est un outil à la fois sûr et extrêmement puissant quand on développe déjà des outils logiciels généraux (ex: des clases utilitaires ; or tout développeur est amené à faire cela régulièrement). D'autant plus que l'ajout des génériques ne modifie en rien la JVM.
Ce que j'apprécie également, c'est que les concepteurs des génériques en Java on repris le côté typage sûr qu'on trouve dans les génériques d'Ada, et absolument pas dans les templates de C++.
 
Pour les enums, je pense que c'était un manque originel de Java. On n'a jamais réussi, avec le langage actuel, à définir des enums qui soient réellement typesafe dans tous les cas (en particulier dès que RMI pointe le bout de son nez, ça devient assez compliqué à gérer). C'est la preuve qu'il manquait un concept dans le langage lui-même.
 
En ce qui concerne l'auto-boxing, je suis plus réticent. De manière générale, j'ai une méfiance naturelle pour l'implicite. Là en gros, il va y avoir des créations d'objet sans qu'on s'en rende vraiment compte. D'un autre côté, j'ai moi aussi pas mal souffert de l'obligation d'écrire "new Integer(...)" ou "new Boolean(...)", alors je peux comprendre cette demande de la part des programmeurs. A voir à l'usage si cette pratique a plus d'avantages ou plus d'inconvénients.
 
Pour le "for" amélioré, je suis tout à fait pour, même si je critique fortement la syntaxe adoptée : comme le disait très justement Taiche, avec le deux-points, cette nouvelle syntaxe perd beaucoup en lisibilité.
Quant aux arguments sur les nouveaux mots-clés, je ferais remarquer que ces arguments étaient déjà valables pour la version 1.4, pourtant cela n'a pas gêné Sun d'ajouter un nouveau mot-clé "assert" à ce moment-là. A mon avis, ça valait largement le coup d'ajouter le mot-clé dans la version 1.5.
Et quitte à utiliser malgré tout le deux-points, il aurait alors fallu à mon avis utiliser un autre mot-clé que "for" pour écrire ce nouveau type de boucle ; par exemple "foreach". Là au moins, on voit tout de suite qu'on parcourt une collection.
Au passage, je trouve dommage qu'on ne puisse pas utiliser cette syntaxe "foreach" pour parcourir un tableau d'objets... Cela éviterait pourtant beaucoup de "ArrayOutOfBoundsException"'s...
 
Pour les imports statiques, c'est contraire à ma façon personnelle d'utiliser Java, qui consiste à toujours préfixer les noms de symboles statiques utilisés par le nom de la classe qui les définit, même si le compilateur ne l'impose pas. De la même manière que mes accès/invocations aux attributs/méthodes de/à l'objet receveur, je les préfixe toujours par "this.". Mais je sais que certains développeurs trouvent cela pénible à écrire.
De toute façon, benou, si tu as un minimum de méthode, tu banniras le "import *". Et en faisant cela, tu retrouveras toujours facilement d'où vient telle ou telle classe importée.
Dès lors que l'"import *" est banni, pourquoi pas, donc.
Enfin, pour les métadonnées (JSR-175), ça peut être une bonne idée (c'est clair que dans l'exemple qu'ils donnent, cela simplifie largement le code. Là encore, je n'ai pas d'avis bien arrêté. A voir à l'usage donc, si cela rend la maintenance plus complexe ou non, sachant que je n'ai pas vraiment de pratique approfondie de RMI.
Ceci dit, je vois un autre usage à ces "métadonnées", qui là aurait un impact bien plus considérable pour les prgrammeurs Java : l'introduction de pseudo-mots-clés pour le support des pré-conditions, post-conditions et des invariants en Java...  

ce truc de metadata, c'est déjà ce que fais xdoclet non?

...

 
Oui, sauf que xdoclet cachait les metadata dans des commentaires javadoc, alors qu'ici, la notion est directement dans le langage.

ha ok, ça ne m'a pas paru evident en lisant la jsr sus-linkée
 
ps: d'ailleurs c'est pas necessairement plus mal que ça soit dans la doc, comme ça cela apparait aussi dans la javadoc standard?

La généricité, c'est vraiment une bonne chose.
Et le J2SE qui implémentera tout ça, il est prévu pour bientôt ?

Lis les liens proposés
La 1.5 est prévue pour la fin de l'année.

bha si, ca marche aussi sur les tableaux le enhanced for ...

Autant pour moi, je n'avais vu aucune référence aux tableaux dans les pages que j'avais lues hier, mais c'est effectivement le cas, détaillé ici.
 
Plus de détails également sur :
  - les enums
  - les imports statiques
  - l'autoboxing

J'aime bien l'exemple que Sun donne pour les enums :  

 
Et surtout sa conclusion :

Tu m'étonnes qu'il est "un peu" tordu...  
Mais plutôt rigolo, je reconnais.

Mais c'est horrible !!!!

le truc c'est que je vois pas bien l'utilité du mot clé "enum" là !?
j'ai du louper un épisode
 
 
... sinon moi un truc que j'aimerais bien pouvoir faire c'est