A propos de J2SE 1.5

Java 5 est une évolution majeure qui remet la syntaxe Java presque au même niveau que celle des langages .Net. Ca fait six ans que je programme avec plaisir en Java mais j'attendais avec impatience ces nouveautés depuis mes débuts en C#.

Salut,


J'apporte juste mon avis sur les nouveautés de Tiger :


static import : Je suis plutôt d'accord avec lunatix, c'est une fonctionnalité a utiliser avec parcimonie...


printf : Je trouve cela super pratique !
Bien entendu il ne faut pas se limiter aux System.out.printf() mais voir ce qu'il y a derrière : la classe Formatter, qui permet de formater tous types de flux...
C'est sûrement parce que je viens du C mais je préfère la syntaxe du printf() à celle des autres classes de formatage de Java (DecimalFormat, etc.).


for étendu : Au delà de la simplification de l'écriture, elle a l'avantage de gérer simplement plusieurs types de collections à partir du moment où ces dernières sont Iterable...
On peut changer fortement le type d'origine de la collection sans avoir à forcement modifier toutes les boucles...


enum : Les types enum sont bien des Objets ! On est bien loin des enum du C/C++ qui correspondait à des int...
Ici on possède de vrai Objet (avec constructeur/Accésseur/méthodes...).
La principale différence avec une classe c'est qu'on ne peut pas crée de nouvelle instance
De plus il y a bien un héritage de la classe Enum (même s'il n'est pas explicite).
C'est nettement plus propre que les solutions du JDK 1.4 (cf la FAQ : http://java.developpez.com/faq/java/?page=divers#LANGAGE_enumeration).


Les arguments variables : Je trouve cela très utile au contraire...
Il faut toutefois savoir que les arguments variables reviennent à utiliser un tableau (même signature de méthode !). Donc la méthode suivante :

Code:

---

public static void m(int ... valeurs) { /* ... */ }

---

Peut être appelé de deux manière :

Code:

---

1 2 3

m (1,2,3); // ou m ( new int[]{1,2,3} );

---

Cela peut être très pratique dans certain cas (par exemple la méthode Class.getMethod()...)
De plus dans le cas précité :

Citation:

---

Envoyé par Pierrot Le Ouf

Ensuite question à deux centimes :

public class NewSynthax
{
public static void fonction(int param1, int param2){ }
public static void fonction(int ... valeurs){ }
}

NewSynthax.fonction( 1, 2 ); // De quelle méthode parle-t-on?

---

C'est bien entendu la méthode fonction(int,int) qui est appelé dans ce cas...
Cela reste logique car lorsqu'on redéfini une méthode cela signifie que l'on souhaite avoir un comportement spécial dans certains cas...
Au passage le même genre de "problème" peut se poser avec de simple objet :

Code:

---

1 2 3 4 5 6 7

public class MaClasse { public static void fonction(Object o){ } public static void fonction(Number n){ } }   NewSynthax.fonction( new Integer(1) ); // Integer hérite de Number...

---

generics : Encore une fois très pratique... et je pense que c'est ce qui manquait le plus à Java...
Toutefois c'est vrai qu'en cas d'abus cela peut devenir illisible !!!!
Mais c'est déjà parfois le cas avec de multiple cast...


Pour finir j'ajouterai que je comprend les critiques de Pierrot Le Ouf, mais elles resultent plus d'un abus des nouvelles syntaxes plutôt que de véritables problèmes...


a++

Citation:

---

Envoyé par Pierrot Le Ouf

C'est pas que je suis contre des "ArrayList<String> list;" qui ne tolère à la compilation que des String pour l'ajout par exemple... Mais à mon avis en ce qui concerne les déclarations de classe ou interface "generic" (parameterized type), ça va :
- créer de la divergence dans les styles de programmation java, d'où une baisse de la compréhension entre développeurs
- rendre le développement java moins "tout public", certes ça va attirer des matheux en mal de programmation fonctionnelle et déclarative s'extasiant devant les qualités formelles de leurs déclarations de types (de classe, pardon...) cependant les nouvelles complexités "generic" risquent de durcir le premier contact entre java et le futur développeur, celui-ci risque donc de consacrer ses premiers "amours" de programmation à autres choses que du java et de garder ses préférences un bon moment d'où à terme une perte de vitalité de la communauté des développeurs java.

---

le generic me rappel le bin vieil ADA par lequel on a commencer a m'apprendre a programmer. Donc inutil de dire que ca va durcir le premier contact des futur developpeur mais ca va peut etre leur eviter de faire n'importe quoi n'importe comment. Avec une bonne utilisation on verra peut etre enfin des programme un peu plus propre. Mais c'est comme tout, on peut toujours faire n'importe quoi avec un tres bon outil !
on n'avait pas besoin d'attendre la sortie du tigre pour pouvoir programmer a la porc !
Je trouve que java a comblé bcp de manque et que c'est une tres grande avancé

Entièrement d'accord. En fait à part les static import dont je ne comprends pas l'intérêt pratique, tout dans cette nouvelle version va selon moi vers un code plus élégant, plus robuste et plus puissant.
Pour moi le problème ne vient pas de Tiger lui même, mais de la jungle autour : il y a tellement de nouveautés dans cette version que la plupart des outils autour de Java ont été comme cloués sur place et résultat, après plus de 6 mois après sa sortie, il n'y a toujours pas de nouvelle version de ant et je connais plein d'outils qui ont encore des ratés à la compilation avec la nouvelle version. A part Tomcat qui était très vite dans le mouvement, j'ai vraiment du mal à trouver des outils de développés compilés avec Java 5 pour Java 5. En fait ce qu'ils ont le plus m*** sur cette version je trouve, c'est l'intégration avec les outils de développement. Et de toute façon même James Gosling l'a reconnu pendant le lancement, cette mise à jour est beaucoup trop grosse et dorénavant ils avanceront par plus petits pas.
En attendant on rame...

Entièrement d'accord avec toi. Remarque : les outils resteront cloués sur place tant que les environnements de développement des développeurs desdits outils ne seront pas à jour.

bonjour,
je me demandais si la version 1.6 va sortir très bientôt , parce qu'"il y a des gens de sun qui l'ont annoncé quelques jours avant.

Citation:

---

Envoyé par zeno

bonjour,
je me demandais si la version 1.6 va sortir très bientôt , parce qu'"il y a des gens de sun qui l'ont annoncé quelques jours avant.

---

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/

a++

Pour compléter ce que dit adiGuba, de la bouche de James Gosling lui-même (the Java Guy himself) ils ne referont plus jamais ce qu'ils ont fait pour Tiger, c'est à dire rassembler autant d'innovations dans une même version et attendre super longtemps pour la sortir. Donc il y a fort à parier que les prochains cycles de realease seront plus courts. Celà dit je pense quand même qu'ils attendront que Tiger soit mieux intégré sur le marché et surtout que J2EE 1.5 soit releasé avant de sortir Mustang.

Comment cela va se passer pour le netoyage de l'API?
Je veux dire, je comprends qu'ils ne veulent pas scinder la communautée en deux; mais quand on sera au jdk 10.0, il sere peut etre temps de supprimer les "erreurs" du jdk 1.0 ....
En fait ce que je voudrais savoir est Est ce qu'il ont envisagé une politique pour cela? Si oui, quoi? Ou peut on avoir des renseignements?

Ben je sais pas si ça répond à ta question mais il y a le mécanisme des deprecated : quand quelque chose est deprecated dans une API ça t'oblige à utilise certaines options pour compiler et/ou exécuter sans erreurs du code qui utilise des choses deprecated. Après la suppression des éléments dépréciés interviennent après un nombre de versions variables, tout dépend du taux d'adaptation des nouvelles API.
De toute façon, c'est pas pour rien qu'on parle de "boulet de compatibilité ascendante", c'est quelque chose de délicat parce que malgré l'évolution, il faut toujours prendre en compte les contraintes de certains utilisateurs, particulièrement chez certains professionnels pour qui une migration de code peut parfois représenter un énorme investissement.

Juste pour information, il faut savoir qu'il est déjà arrivé qu'une méthode qui fut marquée comme étant deprecated tout un temps est à nouveau opérationelle depuis la version 5.

Citation:

---

Envoyé par vbrabant

Juste pour information, il faut savoir qu'il est déjà arrivé qu'une méthode qui fut marquée comme étant deprecated tout un temps est à nouveau opérationelle depuis la version 5.

---

Ah interressant peux tu nous en dire un peu plus, ou nous donner des exemples

Merci

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

Benjamin >> C'est le cas de System.getenv() qui n'est plus déprécié dans Java 5.0...

En ce qui concerne la suppression des méthodes dépréciées, je pense qu'on a encore le temps de voir venir (quasiment toutes les applets utilisent du code 1.1 pour être compatible avec la JVM de Microsoft)...

De plus, en entreprise la migration entre les différentes versions est déjà assez longue... alors si Sun 'casse' la compatibilité ascendande il risque d'y avoir des 'blocages' !!!

a++

Je suis d'accord qu'il ne faut pas gener les entreprises... hormis Microsoft. Leur jvm est connue mais pas pour ce qu'elle devrait...

[pense tres fort]
Je vois pas pourquoi MIcrosoft irait pourrir Java alors que sun n'a rien fait à C#, J++ et cie... (Enfin si je vois pourquoi..., mais c'est pas juste.... Vive le pseudo-non-monopole...)
[/pense tres fort]

Citation:

---

Envoyé par SEMPERE Benjamin

Citation:

---

Envoyé par vbrabant

Juste pour information, il faut savoir qu'il est déjà arrivé qu'une méthode qui fut marquée comme étant deprecated tout un temps est à nouveau opérationelle depuis la version 5.

---

Ah interressant peux tu nous en dire un peu plus, ou nous donner des exemples

Merci

---

Si tu regardes sur cette page,
http://javadiff.sourceforge.net/jdiff/reports/j2se142_j2se150b1/changes/java.lang.System.html#methods
tu verras que la méthode getenv() n'est plus dépréciée. Alors qu'elle le fut depuis J2SE 1.2, si mes souvenirs sont bons, car allait à l'encontre de la sacro sainte portabilité de Java.

Citation:

---

Envoyé par Mobius

le generic me rappel le bin vieil ADA par lequel on a commencer a m'apprendre a programmer.

---

Bienvenue au club (IUT d'aix-en-provence ??)

Citation:

---

Envoyé par Mobius

Donc inutil de dire que ca va durcir le premier contact des futur developpeur mais ca va peut etre leur eviter de faire n'importe quoi n'importe comment.

---

Même avec l'auto (un)boxing ?? J'ai bien peur quen non, le typage on ne sait plus vraiment ce que c'est désormais...

++

Citation:

---

Envoyé par Original Prankster

Citation:

---

Envoyé par Mobius

le generic me rappel le bin vieil ADA par lequel on a commencer a m'apprendre a programmer.

---

Bienvenue au club (IUT d'aix-en-provence ??)

---

et non! ;) j'ai appris au gres de mes differentes rencontre que le langage ADA etait enseigné dans bcp d'IUT. Surement parce qu'il permet d'avoir de bonnes bases.

Citation:

---

Envoyé par Original Prankster

Citation:

---

Envoyé par Mobius

Donc inutil de dire que ca va durcir le premier contact des futur developpeur mais ca va peut etre leur eviter de faire n'importe quoi n'importe comment.

---

Même avec l'auto (un)boxing ?? J'ai bien peur quen non, le typage on ne sait plus vraiment ce que c'est désormais...

++

---

l'autoboxing pose certain problème et certain bug dur a trouver apparaitront surement (cf: http://www.wiki.brosch.net/index.php/Java5/Autoboxing ). Cepandant, je trouve que ca un bon début dans l'evolution de Java. Je trouve en effet, qu'on ne devrait pas entendre parler de type primitif mais uniquement d'objet. Par exemple, l'entier 10 devrait etre vu comme un Integer et non pas comme un int. Pour le moment, l'autoboxin est juste un artefact pour cacher les types primitifs et je ne trouve donc ca pas suffisant. Pour illustrer ce pb, je trouve que le cas des String est bien representatif. On peut en effet directement utiliser une String (par exemple "toto") comme un object.
En résumé je trouve l'autoboxing insuffisant et j'espere que ce n'est qu'un début.

Citation:

---

Envoyé par Mobius

l'autoboxing pose certain problème et certain bug dur a trouver apparaitront surement (cf: http://www.wiki.brosch.net/index.php/Java5/Autoboxing ).

---

Tu veux parler de ceci :

Code:

---

1 2 3 4 5 6

public void beCareful() { Integer i1 = 127; Integer i2 = 127; Integer i3 = 128; Integer i4 = 128; i1.equals(i2); //always true; wrapper types from -127 to 127 are constants -> same object i3.equals(i4); //sometimes (!!!) true; depending on you JVM! Watch out -> bugs hard to find! }

---

Franchement je ne vois pas comment equals() peut renvoyer false dans ce cas !!! 8O

Je pense que l'auteur a confondu avec l'utilisation de l'opérateur == (qui pour des Objects compare les références et non pas les valeurs). Et pour moi c'est normal puisque des objets ne doivent pas être comparé de cette manière...

Cf: L'article sur l'autoboxing sur le blog de Vincent Brabant...


Sinon je suis d'accord avec toi sur le principe du tout objet mais je pense que c'est difficile à mettre en place sans casser la compatibilitée : il faudrait notamment redéfinir les opérateurs entres les classes ainsi qu'un système de cast entre types différents... et il y a surement d'autres éléments qui peuvent amener à des incompatibilitées...

:alerte: Sans parler du fait que l'objet devient transparent, et que le rôle du constructeur est minimisé : le fait de créer une instance sans faire appel de façon explicite au constructeur donne l'impression d'utiliser un type primitif...

Code:

---

Integer i1 = 127;

---

Et puis pourquoi pas aussi :

Code:

---

JLabel lb1 = "Annuler";

---

Sérieux on va où là :?::!::?: :arf: