+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 5 12345 DernièreDernière

Discussion: Le 7/7 c'est Java 7

  1. #1
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 957
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 957
    Points : 3 490
    Points
    3 490

    Par défaut Le 7/7 c'est Java 7

    Java 7 Update 1 corrige l'incompatibilité avec Apache Lucene et Solr
    Due à une optimisation défectueuse du compilateur JIT

    Mise à jour du 27 octobre 2011 par Idelways


    Une anomalie découverte quelques jours avant la sortie de Java 7, et laissée pour compte par manque de temps, vient d'être écartée.

    Oracle sort l'Update 1 de Java 7 qui corrige l'optimisation défectueuse du compilateur Hotspot, responsable de boucles potentiellement erronées, pouvant produire des résultats de calculs incorrects, ou faire crasher la JVM à l'exécution.

    Cette anomalie touchait notamment Apache Lucence, le célèbre moteur de recherche en full TEXT, ainsi que son sous-produit Solr.

    Oracle a sortie cet Update il y a quelques jours, mais n'a mis à jour qu'aujourd'hui les statuts des trois rapports du compilateur "JIT [Just in Time] et les bogues de boucle" signalés par la fondation. D'autres bogues relatifs, découverts en interne, ont été corrigés.

    Uwe Schindler, un contributeur du projet confirme après des tests que l'anomalie a bien été résorbée. Il n'a cependant pas précisé si l'utilisation des flags -XX:+OptimizeStringConcat et -XX:+AggressiveOpts reste toujours recommandée.


    Télécharger Java 7u1

    Source : Oracle, blog d'un contributeur à Apache




    Un bogue sur Java 7 paralyse Apache Lucene et Solr
    Une optimisation défectueuse du compilateur Hotspot incriminée

    Mise à jour du 1 août 2011 par Idelways


    Un sérieux bogue vient d'être dévoilé suite au lancement final de Java 7. Il entrave le fonctionnement de deux projets de la fondation Apache, notamment Lucene, le célèbre moteur de recherche en full-text.

    Le problème se situe plus précisément au niveau du compilateur Hotspot qui intègre un optimisateur défectueux, capable de créer des boucles potentiellement erronées.
    Par conséquent, la machine virtuelle Java peut planter à l'exécution, ou produire des résultats de calculs incorrects.

    Pour Lucene, ce bogue risque de corrompre l'index, plus particulièrement sur la version qui embarque le PulsingCodec.

    L'autre projet phare de la fondation Apache affecté par ce bogue est Solr, le moteur de recherche issu de la bibliothèque Lucene sus-citée.

    Oracle aurait découvert ce bogue 5 jours avant la sortie de Java 7 en version définitive, mais aurait préféré reporter sa correction au deuxième « service release » de Java 7, le premier étant réservé à la correction des bogues de sécurité, sauf changement de planning.

    En attendant, les utilisateurs des deux projets doivent temporiser avant de passer à Java 7 en production ou l'utiliser avec l'option -XX:-UseLoopPredicate qui désactive l'optimisation et met ainsi l'index Lucene à l'abri.

    Un bogue similaire peut surgir sur Java 6 avec les flags -XX:+OptimizeStringConcat et -XX:+AggressiveOpts qui activent des optimisations Hotspot par défaut désactivées.

    Trois rapports de bogues ont été admis par Oracle, l'un de faible priorité et les deux autres de priorité modérée.
    De pareils dysfonctionnements n'ont pas encore été signalés sur des produits autres que ceux de la fondation Apache.

    Pour plus d'informations sur les nouveautés de Java 7, lire ci-dessous.


    Source : avertissement de la fondation Apache

    Et vous ?

    Qu'en pensez-vous de ce bogue ? L'avez-vous rencontré ?



    Java 7 disponible en version finale
    Oracle publie son environnement d'exécution et le JDK 7

    Mise à jour du 29/07/11, par Hinault Romaric

    Après plus de quatre ans depuis la sortie de Java 6, Oracle vient de publier la version finale de Java Runtime Environment (JRE) 7.

    Cette version est la première de Java SE publiée depuis la reprise du langage par Oracle suite au rachat de SUN.

    Java SE 7 apporte un support pour un bon nombre de tendances qui ont déferlé dans le monde du développement informatique depuis la publication de la dernière version. Il offre une prise en charge amélioré des langages dynamique conçus pour fonctionner sur la machine virtuelle Java comme Scala et Groovy.

    Java SE 7 embarque une API permettant de simplifier l’exécution d’un programme à travers des processeurs multi-cœurs. Et plusieurs autres nouveautés importantes (lire-ci avant).

    Le nouveau Runtime Java 7 peut-être utilisé par les développeurs avec les environnements de développement NetBeans ou encore IntelliJ IDEA 10.5. Oracle a annoncé qu’il publiera avant la fin de l’année une mise à jour de son EDI JDeveloper pour un support de Java 7.

    Le Runtime Java 7 est disponible pour les systèmes d’exploitations Linux, Solaris et Windows 32 bits et 64 bits.

    Oracle a également annoncé la disponibilité de la version finale du Kit de Développement de Java 7 (JDK7),

    Télécharger Java 7 sur le site d'Oracle

    Télécharger JDK 7 sur le site d'Oracle


    La RC de Java 7 est disponible
    nio2, coin, javadoc et autres nouveautés

    Enfin ! Plus de quatre ans après la dernière version majeure de Java, Oracle vient d'annoncer la disponibilité de Java 7 en Release Candidate.
    Oracle relance enfin l'évolution de la plate-forme phare qu'est Java qui avait été ralentie par la sortie de JavaFX 1.X et ensuite par le rachat de Sun par Oracle.

    Les nouveautés, si elles sont moins nombreuses qu'initialement espérées (un bon nombre ont été repoussées pour Java 8) sont tout de même importantes. Nous allons en faire un rapide tour d'horizon.

    Le Projet Coin va apporter des nouveautés au cœur du langage.


    Nio2 Le gros morceau à avaler car cela va remplacer l'antique java.io.File (qui reste cependant présent) par une API beaucoup plus moderne et complète. La plupart de ces nouveautés se trouvent dans le package java.nio.File
    • Détection de modification de fichiers grâce à la classe WatchService
    • Une toute nouvelle API de manipulation de fichiers.
    • Gestion des E/S asynchrones
    • Enfin une copie de fichier simple
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      FileSystem default = FileSystems.getDefault();
      Path source  = default.getPath("pets/cat.txt");
      Path target  = default.getPath("nicePets/nicecat.txt");
      Files.copy(source, target);
    • Un support complet des liens physiques et symboliques (si le système de fichier les supporte).
    • Une gestion propre des erreurs, via des exceptions.
    • Un API complète pour l'accès aux attributs des fichiers, qui supporte les fonctionnalités de chaque système (DOS et Posix) ainsi que la gestion des utilisateurs (propriétaire et liste ACL). Le tout parfaitement extensible pour supporter d'autres systèmes de fichiers via des providers. D'ailleurs ce dernier point se concrétise en standard par l'intégration du filesystem "ZIP" qui permet de traiter un fichier ZIP comme un système de fichier standard (ou presque).
      Ainsi pour extraire un fichier d'un ZIP on peut faire ceci (noter l'utilisation du try-with-resource) :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      try (FileSystem zip = FileSystems.newFileSystem(Paths.get("file.zip"), null)) {
          Path source = zip.getPath("pets/cat.txt");
          Path target = Paths.get("nicePets/nicecat.txt");
          Files.copy(source, target);
      }


    invokeDynamic : Une amélioration de la JVM pour les langages dynamiques (Groovy par exemple) mais qui sera utilisable directement en Java via l'API java.lang.invoke. CGlib et JavaAssist vont sûrement beaucoup évoluer.

    Concurrency and collections updates (jsr166y) : pour améliorer vos programmes multi-threadés avec la classe ForkJoinPool

    Plus anecdotique mais quand même bien sympathique :

    un nouveau look beaucoup plus moderne pour la javadoc :



    Et enfin, toute l'API est pleine de petites nouveautés. Par exemple, la nouvelle classe Objects que vous pouvez découvrir avec Adiguba.

    L'annonce sur le site d'oracle
    Télécharger Java 7 sur le site d'Oracle
    La liste officielle des nouveautés

  2. #2
    Membre éclairé Avatar de Lady
    Femme Profil pro
    Développeur Java
    Inscrit en
    mars 2003
    Messages
    672
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Santé

    Informations forums :
    Inscription : mars 2003
    Messages : 672
    Points : 863
    Points
    863

    Par défaut

    Y a certaines des fonctionnalités j'en rêve depuis des années !!

    En fait c'est "rigolo" 2 de ces nouvelles fonctions j'en aurais eu cruellement besoin pas plus tard que lundi dernier ...

    Bon en même temps avant que le projet sur lequel je suis passe en java 7 j'ai un peu de temps.
    (Bio)informaticienne folle ... MOUWAWAWAWA
    Geekette fan de Marcus et de Nolife !!
    Jeune Maman

  3. #3
    Membre émérite
    Avatar de alexismp
    Homme Profil pro
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 725
    Points
    2 725

    Par défaut

    C'est pour l'instant la Release Candidate qui est disponible (build 147). La version finale c'est pour la fin du mois.
    (Juillet)
    (2011!)

  4. #4
    Membre actif
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 203
    Points : 284
    Points
    284

    Par défaut

    Enfin pourrait-on dire !

    Par contre, y'a 2 "fonctionnalités" qui me rebutent un peu :

    *Underscores in numeric literals
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int one_million = 1_000_000;
    //plutôt que
    int one_million = 1000000;
    --> argh mais quelle horreur !
    Il manquerait plus qu'il nous fasse en Java8 la possibilité d'utiliser des chiffres pour nommer des constantes et on y verra plus rien !

    * try-with-resources statement
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
       return br.readLine();
    } finally {
       br.close();
    }
    //pourra s'ecrire :
    try (BufferedReader br = new BufferedReader(new FileReader(path)) {
       return br.readLine();
    }
    --> super, l'exemple nous fait perdre le close() sur notre BufferedReader !!
    Avec le try-with-resource, on peut ajouter des catch et finally (et donc l'exemple est un poil naze là-dessus) ou même pas ?

  5. #5
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2011
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Service public

    Informations forums :
    Inscription : avril 2011
    Messages : 56
    Points : 77
    Points
    77

    Par défaut

    Je peux me tromper, mais si le try-with-resource ressemble a celui que je connais en python, le finally devient optionnel: les ressources ouvertes par le try sont automatiquement fermées a la sortie du bloc!

  6. #6
    Membre éclairé

    Profil pro
    Inscrit en
    mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 264
    Points : 702
    Points
    702

    Par défaut

    Pour les constantes binaires et les underscores dans les littéraux, j'utilise ces deux fonctionnalités depuis quelques années en D et j'avais de plus en plus de mal à m'en passer en Java.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  7. #7
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 518
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 518
    Points : 8 191
    Points
    8 191

    Par défaut

    Citation Envoyé par bhamp0 Voir le message
    *Underscores in numeric literals
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int one_million = 1_000_000;
    //plutôt que
    int one_million = 1000000;
    --> argh mais quelle horreur !
    Il manquerait plus qu'il nous fasse en Java8 la possibilité d'utiliser des chiffres pour nommer des constantes et on y verra plus rien !
    Ce qui est horrible dans l'exemple, c'est surtout d'utiliser les underscores dans les noms de variable alors que Java recommande d'utiliser les majuscules pour démarquer les mots.
    Mais à mon avis, les underscores à l’intérieur d'un chiffre peuvent le rendre bien plus lisible. C'est même limite indispensable avec les littéraux binaires.

    Citation Envoyé par bhamp0 Voir le message
    * try-with-resources statement
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
       return br.readLine();
    } finally {
       br.close();
    }
    //pourra s'ecrire :
    try (BufferedReader br = new BufferedReader(new FileReader(path)) {
       return br.readLine();
    }
    --> super, l'exemple nous fait perdre le close() sur notre BufferedReader !!
    Avec le try-with-resource, on peut ajouter des catch et finally (et donc l'exemple est un poil naze là-dessus) ou même pas ?
    Justement! L'un des principaux intérêt du "try with ressource" est que le close() est fait automatiquement et proprement quand on sort du bloc try.
    On peut rajouter un catch et un finally si on le souhaite, mais la plupart du temps, ça ne sera plus nécessaire.

  8. #8
    Nouveau membre du Club
    Développeur informatique
    Inscrit en
    janvier 2009
    Messages
    51
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2009
    Messages : 51
    Points : 36
    Points
    36

    Par défaut

    Pas mal comme fonctionnalites dans Java7

  9. #9
    Membre averti
    Inscrit en
    mars 2008
    Messages
    283
    Détails du profil
    Informations forums :
    Inscription : mars 2008
    Messages : 283
    Points : 375
    Points
    375

    Par défaut

    Les méthodes de la classe Objects sont vraiment pas mal.

    NIO2 avec les WatchService risquent de laisser faire des choses horribles.
    La première utilité pratique que j'y verrais serais un équivalent à Notepad++. La grosse bêtise à faire serait d'utiliser le système de fichier comme pipe.

    J'attendais le diamant avec impatience !

  10. #10
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 129
    Points : 3 284
    Points
    3 284

    Par défaut

    Mais LOL

    y'a vraiment mais alors vraiment rien de faramineux...

    je me bidonne en lisant la javadoc de la classe Objects... il a, je pense, fallu 2h à un stagiaire pour l'écrire, tests inclus.

    Le try-with-resource est à mon avis le plus utile, mais bon rien d'affolant.

    La nouvelle syntaxe de générique, qui permet de se passer de la notation de droite, est juste ridicule: ok on raccourcis un peu l'expression, mais bon...

    Le multicatch est sympa par contre
    "Si tu avoir un problème et choisir regexp comme solution, maintenant tu avoir 2 problèmes"

    Confucius, 448 av. J-C

  11. #11
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 859
    Points : 7 209
    Points
    7 209

    Par défaut

    Il a fallu quoi? 5 ans bien tapés pour ça?
    Je suis un peu déçu par l'absence d'un sucre syntaxique pour les get/set. Et notre API de date promise censée remplacer cette grosse merde (désolé) de Calendar dans tout ça?

    Quant à la syntaxe en diamant, je trouve que l'inférence de type (le mot clef "var" en C#) aurait été une tellement meilleure solution.

    Avec le try-with-resource, on peut ajouter des catch et finally (et donc l'exemple est un poil naze là-dessus) ou même pas ?
    Avec un peu de chance, ça t'évite d'écrire cette beauté :

    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
     
     
    BufferedReader br = null; 
     
    try 
    {
       br = new BufferedReader(new FileReader(path));
       return br.readLine();
    } 
    finally 
    {
     
        if( br != null)
        {
            try 
            { 
                br.close()
            }
            catch(IOException ex)
            {
                //rien
            }
        }
    }
    }
    J'ai bon espoir que la nouvelle syntaxe étouffe la checked exception sur close().

  12. #12
    Membre éclairé Avatar de Julien Bodin
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2009
    Messages
    470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 470
    Points : 819
    Points
    819

    Par défaut

    Pareil, super déçu.
    La nouvelle API File est sympa, le multicatch aussi.

    Du coup on attend encore 4 ans pour avoir d'autres trucs ?

  13. #13
    Membre actif
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 203
    Points : 284
    Points
    284

    Par défaut

    Citation Envoyé par _skip Voir le message
    Il a fallu quoi? 5 ans bien tapés pour ça?
    Je suis un peu déçu par l'absence d'un sucre syntaxique pour les get/set. Et notre API de date promise censée remplacer cette grosse merde (désolé) de Calendar dans tout ça?

    Quant à la syntaxe en diamant, je trouve que l'inférence de type (le mot clef "var" en C#) aurait été une tellement meilleure solution.



    Avec un peu de chance, ça t'évite d'écrire cette beauté :

    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
     
     
    BufferedReader br = null; 
     
    try 
    {
       br = new BufferedReader(new FileReader(path));
       return br.readLine();
    } 
    finally 
    {
     
        if( br != null)
        {
            try 
            { 
                br.close()
            }
            catch(IOException ex)
            {
                //rien
            }
        }
    }
    }
    J'ai bon espoir que la nouvelle syntaxe étouffe la checked exception sur close().
    OK, ça marche avec les classes "standard" peut-être.
    Mais qu'en est-il si je développe mes propres classes et que j'ai pas close(), mais fermer() ? (malheureusement, y'a des boîtes qui obligent le français dans les noms de méthode)

  14. #14
    Expert éminent
    Avatar de kdmbella
    Homme Profil pro
    Développeur Web
    Inscrit en
    août 2010
    Messages
    799
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2010
    Messages : 799
    Points : 7 025
    Points
    7 025

    Par défaut

    simplement super ces nouveautés de java 7 mais entre la release candidate et la release faut encore du temps quand meme de plus je trouve que Java 6 c'est encore la classe donc la migration c'est pas pour demain dans tous les cas

    au fait le fait que java 7 sorte le 7/7 c'est délibéré ou bien c'est un pur hasard ?
    "L'humanité se divise en trois catégories : ceux qui ne peuvent pas bouger, ceux qui peuvent bouger, et ceux qui bougent."
    - Benjamin Franklin

    De l'aide en Javascript , consultez la FAQ JS.

    De l'aide sur le FrameWork JS DHTMLX : posez vos questions sur le forum des Bibliothèques & Frameworks JS.

  15. #15
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 859
    Points : 7 209
    Points
    7 209

    Par défaut

    Citation Envoyé par bhamp0 Voir le message
    OK, ça marche avec les classes "standard" peut-être.
    Mais qu'en est-il si je développe mes propres classes et que j'ai pas close(), mais fermer() ? (malheureusement, y'a des boîtes qui obligent le français dans les noms de méthode)
    Il faudra pour cela implémenter cette interface :

    http://download.oracle.com/javase/7/...Closeable.html

    Et effectivement, selon la doc d'oracle les exceptions de libération de ressources sont supprimées :

    http://download.oracle.com/javase/tu...sed-exceptions

    Il n'est toutefois pas super bien précisé ce qui se passe si le code automatique génère une exception alors que le code contenu dans le bloc try s'est bien déroulé. Etant donné que autocloseable spécifie un throw Exception de bas niveau, qu'est-ce que cela impliquerait?

  16. #16
    Membre actif
    Profil pro
    Inscrit en
    avril 2009
    Messages
    182
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : avril 2009
    Messages : 182
    Points : 255
    Points
    255

    Par défaut

    le try-with-resource et le multi-catch pour ma part son les meilleurs innovations de java 7. J'espere que java 8 est prevue pour bientot.

  17. #17
    Membre chevronné
    Homme Profil pro
    Développeur .NET
    Inscrit en
    avril 2006
    Messages
    1 618
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2006
    Messages : 1 618
    Points : 2 182
    Points
    2 182

    Par défaut

    Tous les 7 portent bonheur

    Citation Envoyé par _skip Voir le message
    Il a fallu quoi? 5 ans bien tapés pour ça?
    Je suis un peu déçu par l'absence d'un sucre syntaxique pour les get/set. Et notre API de date promise censée remplacer cette grosse merde (désolé) de Calendar dans tout ça?

    Quant à la syntaxe en diamant, je trouve que l'inférence de type (le mot clef "var" en C#) aurait été une tellement meilleure solution.
    Je partage ta déception sur les get/set. Par contre, je préfère la syntaxe diamant au mot-clef var en C#, car à l'utiliser pour tout et n'importe quoi on finit par ne plus savoir ce que l'on manipule comme objet... Personnellement j'adorerais avoir une telle notation à l'instanciation des objet C#

    Le MultiCatch est sympa aussi.

    La classe Objects, on peut se moquer, mais elle permet de faire sûrement et simplement des opérations habituelles, ce qui la rend à mes yeux très séduisante.

  18. #18
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 518
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 518
    Points : 8 191
    Points
    8 191

    Par défaut

    Citation Envoyé par _skip Voir le message
    Il a fallu quoi? 5 ans bien tapés pour ça?
    Je suis un peu déçu par l'absence d'un sucre syntaxique pour les get/set. Et notre API de date promise censée remplacer cette grosse merde (désolé) de Calendar dans tout ça?
    Comme beaucoup des nouveautés prévues, ça arrivera pour Java 8, même si le travail dessus est bien avancé.

    Java 7 est avant tout un signe d'Oracle pour dire : "non, on a pas abandonné Java". Ils ont sorti ce qui était près à l'être mais les majorité des nouveautés clés prévues à l'origine pour Java 7 seront pour Java 8 (lambda, références de méthode, méthode d'extention, collection littératles, Api Date, ...)

    Citation Envoyé par _skip Voir le message
    Quant à la syntaxe en diamant, je trouve que l'inférence de type (le mot clef "var" en C#) aurait été une tellement meilleure solution.
    Je trouve que le mot-clé "var" rend le type moins lisible. Pour moi la lisibilité du type est un gros avantage de java

    Citation Envoyé par _skip Voir le message
    Avec un peu de chance, ça t'évite d'écrire cette beauté :
    ...
    J'ai bon espoir que la nouvelle syntaxe étouffe la checked exception sur close().
    C'est bien le cas

    Citation Envoyé par Julien Bodin Voir le message
    Du coup on attend encore 4 ans pour avoir d'autres trucs ?
    Normalement ça devrait être bien plus rapide : le travail sur les nouveautés a venir est bien entamé. Java 7 est juste une sorte de pré-Java 8.

    Citation Envoyé par bhamp0 Voir le message
    OK, ça marche avec les classes "standard" peut-être.
    Mais qu'en est-il si je développe mes propres classes et que j'ai pas close(), mais fermer() ? (malheureusement, y'a des boîtes qui obligent le français dans les noms de méthode)
    Il suffit que ta classe implémente l'interface AutoClosable et sa méthode close() sera appelée automatiquement. Ta méthode close() pourra faire appel à la méthode fermer().
    Vouloir l'intégralité des méthodes en français est de toute façon impossible en Java (main(), finalize(), ...)

  19. #19
    Membre actif
    Inscrit en
    février 2006
    Messages
    71
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 71
    Points : 207
    Points
    207

    Par défaut

    Perso', j'attends surtout Java 8 pour le projet Jigsaw, avec la gestion des dépendances directement gêrée en Java (modules et dépendances inter-modules ou dépendances vers des jars) (même si çà n'ira sans doute pas super loin, çà mettra un coup de pied dans la fourmillère maven).

  20. #20
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 120
    Points : 48 044
    Points
    48 044

    Par défaut

    Citation Envoyé par _skip Voir le message
    Il a fallu quoi? 5 ans bien tapés pour ça?
    Je suis un peu déçu par l'absence d'un sucre syntaxique pour les get/set. Et notre API de date promise censée remplacer cette grosse merde (désolé) de Calendar dans tout ça?

    Quant à la syntaxe en diamant, je trouve que l'inférence de type (le mot clef "var" en C#) aurait été une tellement meilleure solution.
    A pitié, par les types variant, ca a des tonns de p** d'effets de bord. La syntaxe diamant a pour but d'éviter de ce répéter, pas de créer des types variables.


    Pour le reste, rien de surprenant, ca fait depuis fin 2010 que cette liste de fonctionnalité pour java 7 a été arrêtée. Et les nouveaux responsables du coté d'oracle on été clair "on a pris la liste de ce qui était prévu pour java 7, on a regardé ce qu'on pouvait faire à temps, on a refusé tout le reste". C'est pas agréable, mais au moins c'est responsable. Oracle, contrairement à sun, a respecté les délais qu'il a promis. De toutes façons, si tout ce qui était prévu avait été mis dedans, ben on aurait encore attendu 1an1/2 avant java 7, date à laquelle java 8 va sortir. Donc au final t'aura tes fonctionnalités à la même date
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

Discussions similaires

  1. Le 7/7 c'est Java 7
    Par lunatix dans le forum Actualités
    Réponses: 89
    Dernier message: 02/08/2011, 01h07
  2. Probleme de date entre sql est java
    Par logiciel_const dans le forum SQL
    Réponses: 7
    Dernier message: 31/01/2011, 11h20
  3. le Java est la continuité du C++ ???
    Par Vincent PETIT dans le forum Débats sur le développement - Le Best Of
    Réponses: 33
    Dernier message: 25/08/2005, 20h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo