Publicité
+ Répondre à la discussion
Page 1 sur 6 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 118
  1. #1
    Invité régulier
    Inscrit en
    janvier 2003
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : janvier 2003
    Messages : 8
    Points : 7
    Points
    7

    Par défaut A propos de J2SE 1.5

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

  2. #2
    Membre expérimenté
    Avatar de Glob
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    avril 2002
    Messages
    406
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : avril 2002
    Messages : 406
    Points : 518
    Points
    518

    Par défaut

    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...
    Glob
    All Hell Can't Stop Us Now!

  3. #3
    Membre régulier
    Inscrit en
    janvier 2003
    Messages
    61
    Détails du profil
    Informations forums :
    Inscription : janvier 2003
    Messages : 61
    Points : 70
    Points
    70

    Par défaut

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

  4. #4
    Membre Expert
    Avatar de RanDomX
    Inscrit en
    mars 2003
    Messages
    579
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 579
    Points : 1 109
    Points
    1 109

    Par défaut

    idem pour les generics.


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

    Vivement fin 2003.

  5. #5
    Membre régulier
    Inscrit en
    janvier 2003
    Messages
    61
    Détails du profil
    Informations forums :
    Inscription : janvier 2003
    Messages : 61
    Points : 70
    Points
    70

    Par défaut

    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/

  6. #6
    Inactif
    Inscrit en
    avril 2002
    Messages
    51
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 51
    Points : 42
    Points
    42

    Par défaut

    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.

  7. #7
    Futur Membre du Club
    Inscrit en
    avril 2002
    Messages
    45
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 45
    Points : 17
    Points
    17

    Par défaut

    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.

  8. #8
    hlr
    hlr est déconnecté
    Membre du Club
    Inscrit en
    mai 2003
    Messages
    57
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 57
    Points : 40
    Points
    40

    Par défaut

    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

  9. #9
    Futur Membre du Club
    Inscrit en
    avril 2002
    Messages
    41
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 41
    Points : 15
    Points
    15

    Par défaut

    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?

  10. #10
    Membre éclairé
    Avatar de knotty
    Inscrit en
    mars 2002
    Messages
    127
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 127
    Points : 360
    Points
    360

    Par défaut

    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.
    Christophe Ludet
    Testez vos connaissances Java - http://knotty.developpez.com
    Donner des ailes a votre application (J2EE patterns) - http://knotty.developpez.com/j2ee

  11. #11
    Futur Membre du Club
    Inscrit en
    avril 2002
    Messages
    41
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 41
    Points : 15
    Points
    15

    Par défaut

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

  12. #12
    HRS
    HRS est déconnecté
    Membre expérimenté Avatar de HRS
    Inscrit en
    mars 2002
    Messages
    643
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 643
    Points : 514
    Points
    514

    Par défaut

    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 ?

  13. #13
    Membre éclairé
    Avatar de Greg01
    Inscrit en
    mai 2002
    Messages
    296
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 296
    Points : 376
    Points
    376

    Par défaut

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

  14. #14
    Membre éprouvé
    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 407
    Points
    407

    Par défaut

    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.

  15. #15
    Invité de passage
    Inscrit en
    novembre 2003
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : novembre 2003
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

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

  16. #16
    noa
    noa est déconnecté
    Invité de passage
    Inscrit en
    décembre 2003
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 8
    Points : 3
    Points
    3

    Par défaut

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

  17. #17
    Invité de passage
    Inscrit en
    juin 2002
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : juin 2002
    Messages : 6
    Points : 2
    Points
    2

    Par défaut

    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 :
    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 :
    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;
    	    }
    	}
        }
    }

  18. #18
    Débutant
    Inscrit en
    juin 2002
    Messages
    32
    Détails du profil
    Informations forums :
    Inscription : juin 2002
    Messages : 32
    Points : 10
    Points
    10

    Par défaut

    Ah, je suis bien content qu'il aient changé le Look And Feel "Metal", c'etait vraiment pas beau ce gris avant

  19. #19
    Invité régulier
    Inscrit en
    février 2004
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 27
    Points : 8
    Points
    8

    Par défaut date jdk 1.5 finale

    Bonjour,

    quelqu'un connaitrait-il la date de la version finale du jdk 1.5?

  20. #20
    hlr
    hlr est déconnecté
    Membre du Club
    Inscrit en
    mai 2003
    Messages
    57
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 57
    Points : 40
    Points
    40

    Par défaut Re: date jdk 1.5 finale

    Citation Envoyé par fredericL
    Bonjour,

    quelqu'un connaitrait-il la date de la version finale du jdk 1.5?
    Faut déjà passer le cap de la 1.5.0 beta
    Après avoir regardé dans ma boule de cristal, je dirais dans 6 mois

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •