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(...)
Journal Où l'on en apprend un peu plus sur Java 7
30
mar.
2009
# Erreur ?
Posté par fetchy . Évalué à 6.
# Block ou closure ?
Posté par Ontologia (site web personnel) . Évalué à 1.
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 Laurent A. . Évalué à 6.
- 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 Ontologia (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Block ou closure ?
Posté par Philippe F (site web personnel) . Évalué à 4.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Block ou closure ?
Posté par Philippe F (site web personnel) . Évalué à 1.
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 wismerhill . Évalué à 0.
Ç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 Ontologia (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Block ou closure ?
Posté par Bozo_le_clown . Évalué à 2.
Tu contournes comment avec du Java ? (qui était la remarque initiale)
[^] # Re: Block ou closure ?
Posté par 2PetitsVerres . Évalué à 3.
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 timid . Évalué à 10.
[^] # Re: Block ou closure ?
Posté par alberthier (site web personnel) . Évalué à 1.
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 Ontologia (site web personnel) . Évalué à 3.
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 ndesmoul . Évalué à 1.
Est-ce que certains parmi vous on regarder un peu Scala ? Est-ce un langage potentiellement intéressant ?
[^] # Re: Block ou closure ?
Posté par Victor . Évalué à 2.
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 hsyl20 (site web personnel) . Évalué à 1.
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 Jean-Marc (site web personnel) . Évalué à 2.
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 !
[^] # Re: Block ou closure ?
Posté par Victor . Évalué à 1.
# JSR & Harmony
Posté par vrm (site web personnel) . Évalué à 2.
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 Ramón Perez (site web personnel) . Évalué à -1.
Oooooh, comme c'est original ! La preuve que ce java7 va être super novateur !
# MVM
Posté par pmoret (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.