Discussion :

[adiGuba]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

JLabel lb1 = "Annuler";

Sérieux on va où là ::

On va direct à l'erreur de compilation (type mismatch) puisque "Annuler" est déjà un objet de type String
Plus sérieusement cela n'a aucun sens... L'auboxing ne peut concerner que les types primitifs et leurs classes Wrapper.
Et le typage du langage est conservé, on rapproche juste les types primitifs de leurs objets conteneurs...


Pour moi l'autoboxing est une simple facilité du langage, et je ne pense pas que cela apporte de gros problème...
Le problème du == signalé dans le blog de Vincent est normal, et la même erreur se retrouve souvent lors de la comparaison de String car les débutants ont du mal à voir la différence entre l'opérateur == et la méthode equals()...

[Gfx]

Il se sont aperçu qu'ils ont fait des modification inutiles? C'est comme la methde setVisible(boolean) qui remplace show() mais elle apelle show...

Toutes les méthodes qui remplacent des méthodes deprecated fonctionnent ainsi, elles appellent l'ancienne méthode. Il y a des raisons techniques pour cela qui permettent d'assurer la compatibilité avec les anciens programmes.

[Gfx]

La version 1.6 est toujours en développement et je ne pense pas qu'elle sorte avant quelques temps...

Mais si ca t'intérresse tu peux suivre son développement : https://mustang.dev.java.net/

Les beta devraient arriver d'ici deux mois et la version finale devrait être disponible pour JavaOne 2006, donc au début de l'été prochain.

[TabrisLeFol]

Regarde ici si t'est pressé http://www.zamples.com/

[super_navide]

Java 1.5 avec eclipse le langage le plus puissant possible même si des amélioration sont encore possible

[bigtof]

Est-ce que, par hasard, quelqu'un sait quand sortira java 5.0 update 7 ?

[Gfx]

Je dois verifier mais je crois qu'on a recemment boucle cette update.

[professeur shadoko]

Pour moi l'autoboxing est une simple facilité du langage, et je ne pense pas que cela apporte de gros problème...
.

si ...
par exemple: un short est affectable a un int mais un Short n'est pas affectable a un Integer + les joyeusetes de la resolution de surcharges par le compilateur ....
je veux bien des "facilites" (comme foreach) qui conservent la coherence les autres relevent de la machinTrucChosite aigue.

[Pollux]

si ...
par exemple: un short est affectable a un int mais un Short n'est pas affectable a un Integer + les joyeusetes de la resolution de surcharges par le compilateur

L'autoboxing n'a pas pour but de transformer l'étendue de l'objet ( Short -> Integer) mais de passer entre Wrapper et primitives donc je vois pas le rapport entre le problème que tu soulèves et l'autoboxing.

[afrikha]

si ...
par exemple: un short est affectable a un int mais un Short n'est pas affectable a un Integer + les joyeusetes de la resolution de surcharges par le compilateur ....
je veux bien des "facilites" (comme foreach) qui conservent la coherence les autres relevent de la machinTrucChosite aigue.

Il me semble que tu as mal saisi le rôle de l'autoboxing, ainsi que le contexte dans lequel il doit être employé. Je te renvoie vers ce tutoriel pour de plus amples informations

[professeur shadoko]

Je te renvoie vers ce tutoriel pour de plus amples informations

Le sens de mon message est le suivant:il y a une tendance "naturelle" des langages à tendre vers des considérations byzantines qui sont affaire de spécialistes. On peut certes expliquer sereinement des exemples comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int val = 666 ;
Integer ig = val ; // ok
Short sht = val ; // plantarem lou compilou
Short shti = 666 ; // Mais ça c'est ok
Byte bt = 1 ; // meme idee
bt++ ; // marche
bt = bt + 1 ; // replantation ....

etc etc.
C'est si simple que l'analyseur d'Eclipse se plante sur certaines expressions.
Quant tu combines avec des arguments variables il faut une ceinture 3° dan pour essayer de deviner comment le compilateur va résoudre des surcharges.
ça fait toujours d'excellents sujets de questions pour des tests à choix multiples qui permettront de juger les "bons" programmeurs
---------------------------------------------
"la solution est au problème ce que la mousse est à la bière: tout est toujours évident" Magnus Ridolph

[adiGuba]

Le sens de mon message est le suivant:il y a une tendance "naturelle" des langages à tendre vers des considérations byzantines qui sont affaire de spécialistes. On peut certes expliquer sereinement des exemples comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int val = 666 ;
Integer ig = val ; // ok
Short sht = val ; // plantarem lou compilou
Short shti = 666 ; // Mais ça c'est ok
Byte bt = 1 ; // meme idee
bt++ ; // marche
bt = bt + 1 ; // replantation ....

etc etc.
C'est si simple que l'analyseur d'Eclipse se plante sur certaines expressions.

Mais cela n'a rien à voir avec l'autoboxing mais avec la taille des différents type. D'ailleur on obtient les mêmes erreurs si on n'utilise seulement des types primitifs...

Un int (codé sur 4 octets) ne peut pas forcément tenir dans un short (codé sur 2 octets). Donc le compilateur empêche ce type d'affectation, que tu peux forcer en utilisant un cast (qui indique au compilateur que tu prend le risque d'un éventuel dépassement de capacité) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int val = 666 ;
Short sht = (short)val;

En ce qui concernes les bytes, il ne sont pas prévus pour être utilisé pour du calcul mais pour représenter un octet en mémoire (l'équivalent d'un char en C). Ainsi lorsque tu fais un calcul sur des bytes, le résultats est convertit en int pour éviter des dépassement de mémoire, et donc le résultats ne peut pas être stocké dans un byte sans cast explicite...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Byte bt = 1;
bt = (byte)(bt + 1);

Quant tu combines avec des arguments variables il faut une ceinture 3° dan pour essayer de deviner comment le compilateur va résoudre des surcharges.

J'utilises les arguments variables assez souvent et je n'ai jamais eu de problème... En même temps j'évite d'avoir 15 méthodes à argument variable avec le même nom...

a++

[professeur shadoko]

L On peut certes expliquer sereinement des exemples comme:
...
etc etc.
C'est si simple que l'analyseur d'Eclipse se plante sur certaines expressions.

j'a pas été clair?
Excusez moi.
(j'ai quelques autres critiques sur des lacunes d'orthogonalité dans Java 1.5 mais j'ose plus )

[adiGuba]

(j'ai quelques autres critiques sur des lacunes d'orthogonalité dans Java 1.5 mais j'ose plus )

Il faut oser

Plus sérieusement : il y a des points qui peuvent paraitre bizarre de premier abord, mais il y a toujours une raison. Cela a été longement réflechit par plusieurs personnes compétentes via le Java Community Process, le tout avec un système de vote d'acceptation... Ce n'est pas l'idée farfelue d'un développeur seul dans son coin...

A titre d'exemple la JSR 201 concernant l'autoboxing, les enums, la nouvelle boucle for et les import static a été eu un cycle de vie de près de 2 ans, et la JSR 14 sur les Générics pendant 5 ans...

a++

[professeur shadoko]

Ce n'est pas l'idée farfelue d'un développeur seul dans son coin...

tout à fait: c'est produit par un comité
Bon je plaisante: on doit certes faire des compromis et en faisant avancer le shmilblic on n'est pas toujours sûr de faire quelque chose de totalement cohérent. L'exemple des generics est intéressant:l'experimentation et l'évolution a été remarquable ... mais il est resté des points tordus ou incomplets - au sens de pas totalement cohérent- ... c'est la vie!
A nous d'accepter ces incoherences pour ce quelles sont (souvent limitées en pratique) et de ne pas déifier des productions humaines.

[voyageur]

bonsoir,

je debute sur Java JDK 5 et je trouve que la genericité est tres complexe à comprendre ( contrairement au C++) quand on aborde certains aspects, c'est trop poussée je trouve.

qu'en pensez vous ?

[gokud-o-matic]

bonsoir,

je debute sur Java JDK 5 et je trouve que la genericité est tres complexe à comprendre ( contrairement au C++) quand on aborde certains aspects, c'est trop poussée je trouve.

qu'en pensez vous ?

je ne comprends pas la question. Ou alors je n'ai pas vu tous les aspects de la généricité.
Que je sache, ça consiste surtout à typer des listes ou des modificateurs pour bénéficier des alertes du compilateur sans devoir réécrire le même code pour chaque type et sans devoir mettre du transtypage partout.
Et de fonctionnement, je n'ai vu que l'autoboxing. On déclare l'objet conteneur en donnant en paramètre les classes enfants.
J'ai raté quelque chose?

[miripesage]

bonsoir, je suis nouveau sur ce forum et je viens de tomber sur cette (rubrique)discussion et je me demande quelle est son utilité aujourd'hui et pourquoi le modérateur n'a pas remplacer cette rubrique par une autre plus utile..A suivre.