Journal Où l'on en apprend un peu plus sur Java 7

Posté par .
Tags : aucun
16
30
mar.
2009
Sun a enfin dévoilé quelques informations concernant la prochaine mouture de Java : Java 7 (nom de code Dolphin).
Prévu pour début 2010[1] si tout va bien, cette version devrait apporter les nouveautés suivantes[2] :
* compression des pointeurs pour les architectures 64-bits, afin de les faire tenir dans 32 bits ;
* Un nouveau Garbage Collector (GC) : G1 ;
* Le support des langages non-Java par la VM ;
* Le support amélioré des annotations (telles que "@NonNull", qui permettra des vérifications dès la compilation) ;
* Des améliorations sur les I/O (NIO 2, STCP, SDP, ...) ;
* L'ajout d'une API permettant la "synchronisation" (concurrency en anglais) entre collections ;
* Des améliorations au sein de Swing, certaines venues tout droit de SwingLabs[3], le laboratoire d'incubation de Swing qui propose depuis maintenant quelques années des API pour compléter les manques de Swing ;
* Et tout plein d'autres trucs (amélioration de la pile XML, Unicode 5.1, amélioration de l'architecture du ClassLoader, ...


Oui, mais... À coté de ça, on apprend que Joda-Time[4] (une API de gestion des dates très poussée (date, temps, écarts de temps, périodes, ...)) qui devait rejoindre Java 7 pour venir prêter main forte à la vieillissante classe java.util.Date ne sera pas incluse[5] car elle impliquerait des modifications dans JDBC et NIO2 et que sa JCP ne semble pas avancer des masses.
On apprend aussi[5] que la MVM (qui avait été annoncée en décembre dernier comme une fonctionnalité de Java 7) ne sera pas incluse non plus. Pour info, MVM signifie "Multiple Virtual Machine" et est destinée à pouvoir lancer plusieurs applications au sein d'une seule VM. Point évidemment intéressant pour de l'embarqué (on pense entre autre à Android qui repose massivement sur du Java), mais ce morceau ayant été jugé trop gros, il faudra encore attendre.

Enfin, un changement dans le vocabulaire de Sun semble en effrayer plusieurs[6] : Sun parlerait de plus de JDK 7 et non de Java 7. Plusieurs bloggueurs y voient là une subtilité qui consisterait pour Sun à non pas publier un standard (Java 7) mais une implémentation (JDK 7) d'aucun standard officiel. Les mêmes bloggueurs de se demander si Sun ne chercherait pas par là à mettre des bâtons dans les roues de la concurrence, en les "empêchant" de mettre à jour leurs VM (sur quel standard se baseraient-elles pour l'implémentation ?).

Bref, un point qui reste à surveiller de près, car on se retrouverait (le conditionnel est de mise) avec une version libre (Java 7 sera la première version totalement GPL 3) ne reposant sur aucune JCP.



1 http://openjdk.java.net/projects/jdk7/
2 http://openjdk.java.net/projects/jdk7/features/
3 https://swinglabs.dev.java.net/
4 http://joda-time.sourceforge.net/
5 http://blog.xebia.fr/2009/03/30/revue-de-presse-xebia-102/#E(...)
6 http://blog.xebia.fr/2009/03/30/revue-de-presse-xebia-102/#S(...)
  • # Erreur ?

    Posté par . Évalué à 6.

    Il n'y a qu'un JCP (Java Community Process). Je pense qu'il fallait plutôt parler de JSR (Java Specification Request) car un JSR est une spécification qui est issu d'un groupe formé dans le JCP.
  • # Block ou closure ?

    Posté par (page perso) . Évalué à 1.

    Moi qui doit coder en java toute la journée pour avoir à manger dans mon assiette, ce langage est une souffrance quotidienne.

    J'espère surtout qu'on aura enfin un vrai type block, comme en ruby/smalltalk/lisaac/whatever, ne serait-ce que pour rendre ce langage insuportable.

    Cela dit, le temps qu'on puiss l'utiliser dans un projet en SSII et qu'on soit autorisé à utiliser les blocks...

    http://www.javac.info/closures-v05.html
    http://rickyclarkson.blogspot.com/2007/11/java-7-example-wri(...)

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Block ou closure ?

      Posté par . Évalué à 6.

      Je ne fais que coder en C++ et je ne sais pas du tout ce qu'est une « closure » ou un « block » (dans ce contexte). En allant jeter un coup d'œil aux liens que tu as donné, j'ai cru reconnaître une syntaxe de langages fonctionnels. Donc mes questions sont :
      - est-ce juste une écriture de type « fonctionnelle » ?
      - à pars une plus grande compacité/simplification d'écriture pour certaines fonctions (et c'est déjà pas si mal), est-ce que cela apporte quelque chose ?
      • [^] # Re: Block ou closure ?

        Posté par (page perso) . Évalué à 2.

        Ca touche au fonctionnel. C'est très connu avec Smalltalk qui le permet depuis 72.
        Un block est un objet fonction, qui peut prendre (ça dépend des langages) un ou plusieurs argument et en renvoyer plusieurs.

        Le bloc permet par exemple de définir un test et les boucles, car dans les langages purement objet, le test n'est pas connu par le compilateur : if est juste un message de true et false qui héritent de boolean.

        Cela apporte beaucoup de puissance, comme par exemple pouvoir créer tes propres structures de controle ou tu veux (et pas être limité à for/while).

        Théoriquement, en smalltalk/ruby, tu faire la même chose que caml avec le type block, après, tu n'as évidemment pas le contrôle de typage.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Commentaire supprimé

        Posté par . Évalué à 4.

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: Block ou closure ?

          Posté par (page perso) . Évalué à 4.

          J'ai beau lire et relire la littérature sur les closure, je comprends vraimant pas ce que ça apporte de miraculeux.

          C'est une fonction qui peut être exécutée dans un contexte. Ouai, cool, mais je vois pas la différence avec une fonction qui prend un argument. Ah oui, on peut stoker la fonction. Mais en dehors du pascal, vous connaissez beaucoup de langages où on ne peut pas stocker une fonction ?

          En lisant toujours, il semblerait que la force des "closure" soit de les associer avec un contexte persistent, et que l'ensemble fasse un objet plutôt intelligent. Bon, je peux imaginer que c'est pratique.

          Si j'essaye de formaliser ça à ma façon, ça donnerait :

          # on fait une closure en python
          def get_threshold_tester( threshold ):
          ....def threshold_tester( a ):
          ........return a >= threshold
          ....return threshold_tester

          f = get_threshold_tester( 10 )
          f( 11 ) -> True
          f( 9 ) -> False


          Et ça, ça remplacerait avantageusement :

          # on fait une closure en python mais on oublie que python sait faire des closure simplement

          class ThresholdTester:
          ....def __init__( self, threshold ):
          ........self.threshold = threshold

          ....def test_threshold( a ):
          ........return a >= self.threshold

          v = ThresholdTester( 10 )
          v.test_threshold( 11 ) -> True
          v.test_threshold( 9 ) -> False


          Bon, je ressens pas un gain énorme. C'est certes plus concis avec une closure, mais je sens que le miracle de la programmation avec closure va continuer à m'échapper.
          • [^] # Commentaire supprimé

            Posté par . Évalué à 3.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: Block ou closure ?

              Posté par (page perso) . Évalué à 1.

              Quand les gens parlent de closure, on a toujours l'impression qu'on parle d'un concept révolutionnaire. Je suis déçu de constater que on peut émuler ça trivialement avec des objets, alors que c'est en général un des premiers avantages mentionnés par les afficionados de Ruby.

              Il y a pas mal de fonctionnalités de python me font beaucoup plus triper que ça, et qu'on ne peut pas émuer avec 3 autres lignes de code. Au hasard, le typage dynamique, le changement dynamique de classes d'une instance à la volée.
              • [^] # Re: Block ou closure ?

                Posté par . Évalué à 0.

                Au hasard, le typage dynamique, le changement dynamique de classes d'une instance à la volée.

                Ça ce sont des arguments pour éviter ce langage pour des projets de taille moyenne et à fortiori si c'est développé de façon modulaire par différentes équipes.
              • [^] # Re: Block ou closure ?

                Posté par (page perso) . Évalué à 2.

                L'intérêt des closures en ruby/smalltalk/etc... est qu'on peut créer ses propre structures de controle.
                Dans la lib Lisaac, je me suis par exemple amusé à créer des foreach until, foreach while, foreach only if, bref des structures de controles sur toute sorte d'objet qui peuvent être vraiment utiles dans plein de cas.
                Tu me diras que ça ne sert à rien parce que ton cerveau est conformé à la programmation avec des langages style C. Si tu prend ton pied avec ça, c'est très bien, j'aimerai des fois être comme toi, savoir me contenter et être heureux, voires prendre mon pied dans ces limites... mais après avoir pris une énorme claque de ma vie avec le caml à 20 ans (à l'époque je connaissais dans l'ordre Basic, Pascal, C), maintenant ça me frustre...

                Depuis que j'ai vu ça :
                http://caml.inria.fr/about/taste.fr.html

                On peut définir des fonctions anonymes à l'aide de la construction function :

                sigma (function x -> x * x) [1; 2; 3];;
                - : int = 14

                Polymorphisme et fonctions d'ordre supérieur permettent de définir la composition de fonctions sous sa forme la plus générale :

                let compose f g = function x -> f (g x);;
                val compose : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b =
                let square_o_fact = compose square fact;;
                val square_o_fact : int -> int =
                square_o_fact 5;;
                - : int = 14400


                Si t'as pris l'habitude de penser comme ça, et que ça te gonfle de revenir à des trucs porky ou faut planquer ta fonction dans une classe que tu créée à la volée ou des horreurs de ce genre, tu as besoin des closures. Si t'as jamais connu, ou que les fonctions de fonctions de fonctions te font pas triper, etc... bah passes ton chemin, et soit heureux avec ta façon de coder, c'est le principal !
                Chacun ses gout :-)

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Commentaire supprimé

                Posté par . Évalué à 2.

                Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Block ou closure ?

            Posté par . Évalué à 2.

            Intéressant mais tu raisonnes avec Python en retournant une référence à une fonction.

            Tu contournes comment avec du Java ? (qui était la remarque initiale)
    • [^] # Re: Block ou closure ?

      Posté par . Évalué à 3.

      Moi qui doit coder en java toute la journée pour avoir à manger dans mon assiette, ce langage est une souffrance quotidienne.
      Et encore, tu ne fais pas de l'Ada...
      /me se demande quand même si la transition de l'Ada vers un langage de modélisation depuis hier est un progrès...

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Block ou closure ?

      Posté par . Évalué à 10.

      Je me demande bien ce que tu codes pour que le manque de closures soit "une souffrance quotidienne"
    • [^] # Re: Block ou closure ?

      Posté par (page perso) . Évalué à 1.

      Les classes anonymes qui implémentent Runnable (ou une classe à toi qui prend les bons paramètres) ça fait pas un peu la même chose ?

      J'ai toujours cru que Java préférait ajouter des fonctionnalités en tant que librairie plutôt que de surcharger le langage. C'est une approche que je trouve raisonnable mais qui provoque apparement pas mal de frustrations
      • [^] # Re: Block ou closure ?

        Posté par (page perso) . Évalué à 3.

        Euhh... Je vais encore prêcher ma chapelle, mais c'est seulement pour te donner un exemple.
        La spec 0.3 de Lisaac, en cours d'implémentation démontre que tu peux avoir des fonctionalités très avancées, tout en ayant un langage beaucoup plus petit que Java (en taillle de grammaire et en nombre de primitives) :
        - Existence du type block (le type fonction)
        - listes (je peux écrire +(foo,bar) : (INTEGER,INTEGER) )
        - templates à la c++
        - Gestion de la concurrence intégré
        - Tout est objet (comme en ruby/smalltalk/...) les entiers, les chars, etc...
        - etc...

        Et c'est valable pour plein de langages

        Bref, il faut se défaire de l'idée que "beaucoup de fonctionalités = gros langage pléthorique".

        Java est un gros langage : sa grammaire est énorme (40ko de texte tout de même), le nombre de mot clé est assez important, etc...

        Bref, s'il était pas une sorte de C++ propre comme il a été pensé au début, il pourrait offrir plus de fonctionnalités et être moins gros...

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Block ou closure ?

          Posté par . Évalué à 1.

          Une JVM permet de faire tourner d'autres langages que Java tout en pouvant utiliser les API purement Java (et vice versa). On peut donc coder en python (Jython), en Ruby (JRuby), Groovy, tous trois des langages de "script", mais aussi dans d'autres langages "compilés" comme Scala, qui a, si j'ai bien compris, des propriétés de langage fonctionnel (mais je n'en sais guère plus).

          Est-ce que certains parmi vous on regarder un peu Scala ? Est-ce un langage potentiellement intéressant ?
          • [^] # Re: Block ou closure ?

            Posté par . Évalué à 2.

            Est-ce que certains parmi vous on regarder un peu Scala ? Est-ce un langage potentiellement intéressant ?

            Je n'utilise plus que Scala depuis moins d'un an, et j'en suis ravi !

            C'est vraiment une joie, autant au niveau de la simplicité de coder par rapport à Java :
            * inférence de type
            * pattern matching, etc...
            qu'au niveau des possibilités :
            * système de typage avancé (par rapport à Java, mais aussi par rapport à d'autres je crois, mais j'y connais rien :)
            * objet (plus que java : pas d'opérateur, pas de type int, float...
            * fonctionnel (les functions sont des objets) mais on peut faire de l'impératif,
            * interop avec le bytecode java donc avec des millions de libs, etc...

            Enfin bon, rien de mieux qu'un petit "Tour of Scala" :
            http://www.scala-lang.org/node/104

            Sinon, ça commence à être utilisé en entreprise, il y a de plus en plus de blog qui racontent comment ils sont passés à Scala, ou comme tel ou tel truc industriel marche bien avec Scala, etc...

            Enfin bon, j'adore :D C'est le futur de mon point de vue.
            • [^] # Re: Block ou closure ?

              Posté par (page perso) . Évalué à 1.

              Tout à fait d'accord. Scala est un langage extrêmement intéressant.

              Les concepts fondateurs de Scala sont :
              - pouvoir mélanger de la programmation impérative avec de la programmation fonctionnelle en gardant le meilleur des deux "styles" et sans que l'un ne prévale sur l'autre
              - avoir une syntaxe suffisamment abstraite et puissante pour permettre "d'étendre le langage" à travers des bibliothèques

              Ce deuxième point évitera d'avoir un langage avec des ajouts mal intégrés (exemples : OpenMP pour le C, C++ tout court, etc.)

              Les gros points forts sont :
              - la compatibilité quasi-totale avec Java (à quelques problèmes d'annotations près). Donc réutilisation du code facile et mixage entre les deux langages possible.
              - le typage statique avec inférence de type qui permet d'avoir un code très épuré et lisible
              - la courbe d'apprentissage qui peut ne pas être trop violente. Il est possible de coder comme en java à quelques détails syntaxiques près
              - bon support dans les IDE (netbeans, eclipse...) et par maven

              Une des critiques que l'on retrouve souvent est que le langage est trop compliqué. En fait, ceux qui souhaitent ajouter une "fonctionnalité au langage" (donc sous forme de bibliothèque) peuvent avoir à écrire du code assez compliqué. Mais une fois ce code écrit, l'utilisation de la bibliothèque est généralement triviale (si elle est bien faite). Voir par exemple la bibliothèque des Actors inspirée d'Erlang ou le framework web Lift.

              Pour vous faire une idée, je vous recommande de lire la série d'articles ici :
              http://www.codecommit.com/blog/scala/roundup-scala-for-java-(...)
        • [^] # Re: Block ou closure ?

          Posté par (page perso) . Évalué à 2.

          Le coté "verbeux" de Java est voulu et nécessaire, c'est un langage de compromis...
          Je code aussi du Java pour manger. Mon cœur penche pour le Scheme / Lisp, j'admire la beauté du langage, mais JAMAIS je ne l'utiliserais pour coder en équipe !
  • # JSR & Harmony

    Posté par (page perso) . Évalué à 2.

    Effectivement, le manque de spécifications et de kit de validation librement accessible commence à faire grincer pas mal de dents, surtout du coté d'Apache (Harmony).
    http://www.jroller.com/scolebourne/entry/no_more_java_7 explique bien le problème.
    Le conflit ne date pas d'hier, cela fait deux ans que l'ASF se plaint du comportement de Sun a propos des kits de test de compatibilité c.f. : http://www.apache.org/jcp/sunopenletter.html

    Mettre le JDK sous licence Open Source, pourquoi pas, mais pourquoi bloquer les spécifications ? A part pour que Sun garde son monopole sur Java, je ne vois pas d'autre explications.
  • # codename: dolphin

    Posté par (page perso) . Évalué à -1.

    dolphin...
    Oooooh, comme c'est original ! La preuve que ce java7 va être super novateur !
  • # MVM

    Posté par (page perso) . Évalué à 1.

    petite correction: MVM signifie Multi-tasking Virtual Machine, et pour plus d'infos sur le principe ( qui n'est par ailleurs pas si nouveau, la publication datant de 2001 :D ) : http://research.sun.com/projects/barcelona/papers/oopsla01.p(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.