A propos de J2SE 1.5 [Débat]

**laffreuxthomas** · 31/03/2005, 15h33

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

**adiGuba** · 05/04/2005, 12h55

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 :

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

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

Peut être appelé de deux manière :

Code :

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

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é :

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 :

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

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

**Mobius** · 08/04/2005, 14h59

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é

**rozwel** · 10/04/2005, 06h09

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

**laffreuxthomas** · 10/04/2005, 13h45

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.

**zeno** · 01/06/2005, 19h24

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.

**adiGuba** · 01/06/2005, 19h36

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

**rozwel** · 02/06/2005, 06h37

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.

**TabrisLeFol** · 22/07/2005, 16h45

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?

**rozwel** · 24/07/2005, 18h58

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.

**vbrabant** · 24/07/2005, 21h20

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.

**SEMPERE Benjamin** · 24/07/2005, 23h13

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

**TabrisLeFol** · 24/07/2005, 23h27

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

**adiGuba** · 24/07/2005, 23h27

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

**TabrisLeFol** · 24/07/2005, 23h37

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]

**vbrabant** · 24/07/2005, 23h56

Envoyé par SEMPERE Benjamin

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.

**Original Prankster** · 02/08/2005, 16h22

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

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

++

**Mobius** · 03/08/2005, 20h12

Envoyé par Original Prankster

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.

Envoyé par Original Prankster

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.

**adiGuba** · 03/08/2005, 20h34

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 :

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

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

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

**Original Prankster** · 04/08/2005, 09h32

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 :

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