A propos de J2SE 1.5 [Débat]

**palacemusic** · 13/05/2003, 14h02

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

**Glob** · 13/05/2003, 14h10

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

**iolco51** · 13/05/2003, 16h06

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

**RanDomX** · 13/05/2003, 17h05

idem pour les generics.

Le mecanisme des templates c'est tellement important...

Vivement fin 2003.

**iolco51** · 14/05/2003, 19h30

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/

**Traroth** · 15/05/2003, 15h05

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.

**corwin_d_ambre** · 15/05/2003, 17h44

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.

**hlr** · 22/05/2003, 10h31

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

**MasterMic** · 22/05/2003, 13h23

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?

**knotty** · 22/05/2003, 20h35

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.

**MasterMic** · 23/05/2003, 10h12

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:

D'ailleurs, je viens de m'apercevoir que moi-même dans mes programmes, j'utilise régulièrement in comme variable

Je devais être fatigué

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

**HRS** · 16/09/2003, 10h57

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 ?

**Greg01** · 23/09/2003, 23h19

Envoyé par HRS

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 ?

Gagné ! La version du JRE (runtime) du client doit être supérieur ou égale à la version du JDK qui a compilé l'appli.

**laffreuxthomas** · 30/09/2003, 15h54

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.

**snicolas** · 25/11/2003, 22h29

Envoyé par laffreuxthomas

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.

Je ne suis pas d'accord. Voici un exemple tres simple

Code :

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

1
2
3
4
5
6
7
8
StringBuffer sb = new StringBuffer(10);
StringBuffer sb2 = new StringBuffer(10);
 
s.append("a");
 
s2.append("b");
 
s.append(s2);

compiler en 1.3 le code marche et s'execute en 1.4 et 1.3
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.

**noa** · 05/01/2004, 16h55

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

**Replouf66** · 13/01/2004, 00h13

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é

, j'ai des erreurs de syntaxes, j'ai pourtant fais une simple copie du code cité dans l'interview :

Code :

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

1
2
3
4
5
6
7
8
9
10
	List<String> words = new ArrayList<String>();
 
	words.add( "This" );
	words.add( "  is" );
	words.add( "   cool :)" );
 
	for(String str : words )
	{
	  System.out.println( str.trim() );
	}

Donc si quelqu'un d'aussi curieux que moi a réussi a utiliser la nouvelle syntaxe, ça serait sympa qu'il nous dise comment

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
 
import java.util.LinkedList;
import java.util.Collections;
import static java.lang.Math.*; // import static
 
class Test {
 
    // enum
    enum Color { red, green, blue };
 
    // varargs
    public static void printf(String fmt, Object... args) {
	int i = 0;
	// foreach on primitive array
	for (char c : fmt.toCharArray()) {
	    if (c == '%')
		System.out.print(args[i++]);
	    else if (c == '\n')
		System.out.println();
	    else
		System.out.print(c);
	}
    }
 
    public static void main(String[] args) {
 
	// Integer list
	LinkedList<Integer> xs = new LinkedList<Integer>();
	xs.add(new Integer(0)); xs.add(new Integer(1));
	Integer x = xs.iterator().next();
	Integer mb = Collections.max(xs);
 
	// string list
	LinkedList<String> ys = new LinkedList<String>();
	ys.add("zero"); ys.add("one");
	String y = ys.iterator().next();
 
	// string list list
	LinkedList<LinkedList<String>> zss = new LinkedList<LinkedList<String>>();
	zss.add(ys); 
	String z = zss.iterator().next().iterator().next();
 
	// foreach on a collection
	for (String s : ys)
	    System.out.println(s);
 
	// varargs and boxing
	printf("Addition: % plus % equals %\n", 1, 1, 2);
 
	// use static import
	printf("sin(PI/12) = %\n", sin(PI/12));
 
	// use enums
	printf("Colors are %\n", Color.values());
	for ( Color c : Color.values() ) {
	    // switch on enum
	    switch(c) {
	    case red:
		System.out.println("found red.");
		break;
	    case green:
		System.out.println("found green.");
		break;
	    case blue:
		System.out.println("found blue.");
		break;
	    }
	}
    }
}