Les spécifications de Java SE 7 et 8 sont adoptées par le JCP, JDK 7 atteint le stade « Feature Complete »

[Uther]

Envoyé par _skip

Alors là ce serait quelque chose! J'utilise actuellement Lombok (voir le lien actualité sous mon pseudo) pour simuler les propriétés mais il manque le support de la javadoc.

Moi aussi, je l'attend depuis très longtemps, mais vu que ça n'a pas encore été réellement mis sur la table, je doute que ça soit prêt pour Java 8

Envoyé par tomlev

try-with-resources: c'est exactement la même chose que les blocs using de C#. Je suppose que les types utilisés avec cette syntaxe doivent implémenter une interface spécifique ? Ce n'est pas précisé dans l'article d'adiGuba

Oui il y aura l'interface AutoCloseable à implémenter pour cela.

Envoyé par tomlev

expressions lambda (dommage que la syntaxe proposée soit un peu trop "verbeuse" par rapport à celle de C#)

Personnellement, je trouve la syntaxe C# trop courte. D'habitude j'aime faire court, mais enfermer un lambda entre accolade,prenthèse,... me semble un minimum pour rester lisible.

Je préfèrais la première syntaxe proposé pour les lambda Java #(x){x*x}; à la dernière: #{x->x*x} . Elle collait plus à ce que l'on voit habituellement en Java(paramètres entre parenthèse, code dans le bloc).
J'ai du mal à voir pourquoi rajouter un nouveau symbole "->" qui en plus ne me parait pas vraiment adapté car il n'y a pas vraiment de pas de notion de déplacement.

[tomlev]

@adiGuba, merci pour les précisions

Envoyé par adiGuba

La syntaxe n'est pas définitive et à déjà beaucoup changée (et rien ne dit que cela ne changera pas encore).
Pour info la version "courante" est décrite ici : State of the Lambda

Pour moi cela reste relativement proche de celle du C# :

Code :

Effectivement, c'est mieux
Ce que j'avais vu semblait nettement plus lourd...

Envoyé par Uther

Personnellement, je trouve la syntaxe C# trop courte. D'habitude j'aime faire court, mais enfermer un lambda entre accolade,prenthèse,... me semble un minimum pour rester lisible.

Je pense que c'est une question d'habitude... dans les cas simples, c'est parfaitement compréhensible avec la syntaxe "compacte". Mais rien n'empêche d'être plus explicite :

Code C# :

1
2
3
4
5
// Cette instruction :
Func<Foo, string> selector = f => f.Name;
 
// Est équivalente (sémantiquement) à :
Func<Foo, string> selector = (Foo f) => { return f.Name; };

[Uther]

Envoyé par adiGuba

// Java 8 (version "courante") :
MyOperator multiply = {l, r -> l * r};

La dernière fois que j'avais noté un changement, il me semble bien qu'il fallait encore un # devant le bloc.
C'est un oubli ou ça encore changé?

[_skip]

Envoyé par adiGuba

Son report été déjà connu depuis bien longtemps...

Ca commençait à devenir difficile de savoir ce qu'ils brassaient franchement...

Envoyé par Uther

Moi aussi, je l'attend depuis très longtemps, mais vu que ça n'a pas encore été réellement mis sur la table, je doute que ça soit prêt pour Java 8

En 2018 ça devrait être bon...

[adiGuba]

Envoyé par Uther

La dernière fois que j'avais noté un changement, il me semble bien qu'il fallait encore un # devant le bloc.
C'est un oubli ou ça encore changé?

Non c'est un oubli de ma part en effet :

Code :

1
2
3
4
5
// C# 3.0 :
myOperator multiply = (l, r) => l * r;
 
// Java 8 (version "courante") :
MyOperator multiply = #{l, r -> l * r};

Par contre comme je l'ait dit et comme le signale tomlev il y a du type-inference ce qui fait qu'on n'a pas forcément besoin de déclarer les types des paramètres. En clair c'est équivalent à ceci :

Code :

1
2
3
4
5
// C# 3.0 :
myOperator multiply = (double l, double r) => l * r;
 
// Java 8 (version "courante") :
MyOperator multiply = #{double l, double r -> l * r};

Mais il ne faut pas vraiment s'attarder sur la syntaxe. L'objectif actuel du projet Lambda est de proposer un prototype complet et fonctionnel. Les débats sur la syntaxe auront lieu plus tard...


a++

[Uther]

En effet mais je trouve bizarre qu'Oracle signale en permanence sur la mailing list que la syntaxe, n'est pas a débattre, que le but est d'avoir un prototype fonctionnel en premier, alors qu'il ont pris la peine de modifier la syntaxe du prototype plusieurs fois.

[adiGuba]

Justement il y a déjà eu plusieurs débats sur la syntaxe.
Je n'ai plus l'URL mais il y avait même une page qui répertoriait les différentes propositions de syntaxe pour les expressions Lambda, et il y en avait près de 20 !!! Et chaque fonctionnalité apportait son débat sur la syntaxe...


Dans un sens ce n'est pas plus mal...

a++

[Uther]

Envoyé par tomlev

Je pense que c'est une question d'habitude... dans les cas simples, c'est parfaitement compréhensible avec la syntaxe "compacte". Mais rien n'empêche d'être plus explicite :

Code C# :

Il n'y a rien a faire, utiliser une flèche pour des lambda me choque, d'autant plus en C# ou elle n'est pas enfermée dans un bloc.
Dans sa signification mathématique aussi bien que dans la vie courante, la flèche à une notion de déplacement et la double flèche ont une notion de conséquence.
Aucune de ces notions ne me paraissent vraiment bonne pour représenter une lambda.

Quand je vois :
Func<Foo, string> selector = f => f.Name; , j'ai beau le savoir, je lutte pour empêcher mon cerveau de se dire:
Func<Foo, string> selector = f à pour conséquence : f.Name;

[Traroth2]

Juillet 2011 ? Et pourquoi pas 2020 ? Démarré en 2006, Java 7 était initialement attendu en 2008, si je ne m'abuse. Je ne veux pas dire que je l'attendais d'un jour à l'autre, mais au premier trimestre 2011, ça aurait pu encore paraitre vaguement raisonnable. Ça fait 3 ans de retard ! Java 7 est en passe de devenir le "Duke Nukem for ever" des langages de programmation !

D'autant plus qu'énormément d'innovations importantes, et surtout Jigsaw, passent à la trappe !

L'un des rares effets positifs qu'on aurait pu attendre du rachat de Sun par Oracle, c'est que les projets auraient plus de moyens. Et là aussi, on est déçu, au final...

[adiGuba]

Envoyé par Uther

Aucune de ces notions ne me paraissent vraiment bonne pour représenter une lambda.

Et ce serait quoi ta syntaxe préféré pour les expressions lambda ???

a++

[tomlev]

Envoyé par Uther

Il n'y a rien a faire, utiliser une flèche pour des lambda me choque

Le concept des expressions lambda vient des langages fonctionnels, et beaucoup d'entre eux (OCaml, F#...) utilisent une flèche, je pense que c'est pour ça... cela dit c'est généralement une flèche simple, et non double

[Uther]

Envoyé par tomlev

Le concept des expressions lambda vient des langages fonctionnels, et beaucoup d'entre eux (OCaml, F#...) utilisent une flèche, je pense que c'est pour ça... cela dit c'est généralement une flèche simple, et non double

En effet, je ne suis pas un habitué des langages fonctionnels.

Envoyé par adiGuba

Et ce serait quoi ta syntaxe préféré pour les expressions lambda ???

a++

Comme dit plus haut la syntaxe #(x){x*x} me plait beaucoup car je trouve qu'elle est plus en accord avec la syntaxe habituelle de Java : les paramètres sont déclarés entre les parenthèses, ensuite vient le bloc de code qui les utilise, comme c'est déjà le cas pour les méthodes et les blocs catch.

[adiGuba]

@Uther : je suis globalement d'accord avec toi... même si après je pense que c'est surtout une question d'habitude.

Du moment qu'on a une syntaxe brèves, l'important se situe au niveau des possibilités que cela offre...

a++

[XData]

Ce serait bien de faire évoluer swing (ajout d'un vrai dateTimePicker par défaut, etc.) ainsi que d'améliorer l'intégration aux divers système d'exploitation avec des thèmes, parce que les applis destop actuelles font un peu tâche par exemple sur windows. Je sais que java est majoritairement utilisé pour les applis web/services mais c'est pas une raison.

Et puis des concurrents sérieux à XAML/Silverlight et LINQ !

Bref s'inspirer de MS sur certains points

Mais bon j'en demande sûrement trop mais c'est bon de rêver

Concernant harmony je vois pas vraiment le problème que ça pose à Oracle. Si des personnes veulent développer une JVM qui respecte les spécifications officielles il n'y a pas de problèmes comme ce qu'avait fait MS à l'époque.

Et puis à eux de promouvoir OpenJDK si ils le jugent meilleur, ce qui tient en grande partie à eux (qu'il soit "meilleur").

[adiGuba]

Envoyé par XData

ainsi que d'améliorer l'intégration aux divers système d'exploitation avec des thèmes,

Swing dispose déjà d'un LookAndFeel natif pour les principales plateformes... dont Windows bien sûr...

Envoyé par XData

Si des personnes veulent développer une JVM qui respecte les spécifications officielles il n'y a pas de problèmes comme ce qu'avait fait MS à l'époque.

La JVM de MicroSoft ne respectaient pas les spécifications... d'où le procès à l'époque.


a++

[XData]

Envoyé par adiGuba

Swing dispose déjà d'un LookAndFeel natif pour les principales plateformes... dont Windows bien sûr...

http://www.apl.jhu.edu/~hall/java/Sw...orial-LAF.html

Sur cette page, le LookAndFeel Windows correspond plutôt à 2000/XP qu'à Windows 7. On remarque tout de suite que ce n'est pas du natif, l'apparence des polices, les couleurs, etc.

Après j'ai peut-être mal cherché, je vais regarder ce que je trouve !

Envoyé par adiGuba

La JVM de MicroSoft ne respectaient pas les spécifications... d'où le procès à l'époque.


a++

En fait je voulais dire que ce qu'avait fait MS à l'époque posait problème justement, mais ma phrase n'est pas très claire



Sinon, ce serait bien aussi qu'Oracle signe un accord avec Google pour remplacer J2ME par ce qu'utilise Android.

[Uther]

Envoyé par XData

Ce serait bien de faire évoluer swing (ajout d'un vrai dateTimePicker par défaut, etc.) ainsi que d'améliorer l'intégration aux divers système d'exploitation avec des thèmes, parce que les applis destop actuelles font un peu tâche par exemple sur windows. Je sais que java est majoritairement utilisé pour les applis web/services mais c'est pas une raison.

Le look&feel du système n'est pas utilisé par défaut pour assurer un affichage identique quelque soit la plateforme. Mais il est disponible tres simplement.
Il suffit de faire un petit:

Code :

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Envoyé par XData

Concernant harmony je vois pas vraiment le problème que ça pose à Oracle. Si des personnes veulent développer une JVM qui respecte les spécifications officielles il n'y a pas de problèmes comme ce qu'avait fait MS à l'époque.

Et puis à eux de promouvoir OpenJDK si ils le jugent meilleur, ce qui tient en grande partie à eux (qu'il soit "meilleur").

Je pense que ce qui fait peur à Sun/Oracle, c'est surtout que ça incite les constructeurs de mobile à utiliser Harmony comme base pour les JVM sur leur téléphone, comme l'a déjà fait Google pour son SDK Android.
La licence apache permet en effet de réutiliser le code sans presque aucune restriction dans une application propriétaire ou non.

Oracle se fait pas mal d'argent en vendant le droit d'utiliser leur implémentation de référence de leur JVM et il n'a pas envie de se priver de cette rentrée d'argent substantielle.

[adiGuba]

Envoyé par XData

Sur cette page, le LookAndFeel Windows correspond plutôt à 2000/XP qu'à Windows 7.

Cette page est copyrighté en 1999, et montre une demo de SwingSet qui a été remplacé par SwingSet2 depuis bien longtemps.
Donc oui cela ressemble à du Windows 2000 (voir 98), et je pense que cela dois tourner sur du Java 1.2...

Envoyé par XData

On remarque tout de suite que ce n'est pas du natif, l'apparence des polices, les couleurs, etc.

Sauf erreur de ma part sur la version, depuis Java 5.0 on utilise un LnF système qui récupère directement les composants natifs de l'hôte, pour un rendu bien plus proche.

Envoyé par XData

Après j'ai peut-être mal cherché, je vais regarder ce que je trouve !

Tu peux vérifier cela assez facilement en lançant la demo de SwingSet2 ou de SwingSet3 via Java Web Start
Ces deux te permettent de changer dynamiquement le Look and Feel...


a++

[Uther]

Envoyé par XData

http://www.apl.jhu.edu/~hall/java/Sw...orial-LAF.html

Sur cette page, le LookAndFeel Windows correspond plutôt à 2000/XP qu'à Windows 7. On remarque tout de suite que ce n'est pas du natif, l'apparence des polices, les couleurs, etc.

Tes captures datent vraiment beaucoup. Les look&feel des vieilles versions de java étaient en effet approximatifs.

Mais sur les versions plus récentes, les différences sont difficiles à trouver. Avec le code que j'ai posté si dessus, le look& feel correspondant au système est directement utilisé. Quant au L&F Windows Vista, il correctement supporté par tous les JRE sortis après (et même un peu avant) l'OS.

[XData]

Merci à vous deux pour ces éclaircissements ;-)

Pour le look and feel, après quelques tests, je reconnais que l'intégration au système hôte et de loin meilleur que ce que j'imaginais !