Sinon, un chiffon imbibée d'huile (par exemple de Tournesol) sera peut-être efficace.
En tout cas ça l'est pour retirer facilement la colle d'étiquettes collées sur du verre. Évidemment ne pas trop asperger d'huile non plus, car il va falloir rincer et "dégraisser" après.
Il y a d'autres solutions cryptographiques bien moins onéreuses en calcul que celles basées sur de la block chain. Elles restent centralisées par contre.
Et je parle de solutions où une carte à puce a une puissance suffisante pour faire les calculs côté client et où le commerçant n'a besoin que d'un mobile pour vérifier la transaction de manière off-line. Quand la "banque" reçoit les transactions du commerçant elle doit tout de même faire des calculs supplémentaires pour détecter des possibles cas de fraude, mais ça reste raisonnable.
Le consommateur est anonyme lors d'un paiement aussi bien du point de vue de la banque que du commerçant. Le commerçant par contre n'est pas anonyme, donc pas de paiement au noir.
La banque n'a techniquement la possibilité de lever l'anonymat d'un payeur qu'en cas de rejeux de certains éléments dans une autre transaction. Dans ce cas, et uniquement dans ce cas, la comparaison des deux transactions permet de lever l'anonymat.
Ce type de solution paraît offrir un bon compromis entre protection de la vie privée et lutte contre la fraude.
D'un autre côté il est techniquement possible d'offrir un système de paiement électronique garantissant un certain anonymat:
Ça prendra sans doute la forme d'un système de porte-monnaie électronique rechargeable :
soit une carte achetée anonymement, mais dont l'usage sera traçable. Pas idéal, mais déjà mieux que rien.
soit, à mon avis mieux, un système où tu n'es pas anonyme lors d'un rechargement, mais anonyme lors de l'usage. Assez similaire, du point de vue protection de la vie privée, à un paiement avec des billets retirés auprès d'un distributeur avec sa carte bancaire. Là ça demande un peu plus de crypto, mais c'est tout à fait faisable y compris intégré sur carte à puce.
Idéalement un tel système peut être embarqué dans un mobile (+SIM ou TEE) pour pouvoir facilement réaliser un rechargement en ligne.
Précisons que bien qu'offrant un certain anonymat, ce type de système permet de détecter les fraudes et de lever l'anonymat si besoin.
Donc on peut avoir quelque chose assurant une meilleure protection de la vie privée tout en conservant la plupart des avantages du paiement électronique, y compris donc sur la détection de fraude.
C'est valable dans d'autres domaines comme les cartes de transport : il est tout à fait possible techniquement d'avoir une carte sure du point de vue du transporteur (pas de fraude), qui garantisse à l'usager qu'il ne sera pas traçable lors de ses trajets.
Il me semblerait sain de pouvoir choisir d'utiliser ce type de système, au moins pour des petits montants de tous les jours. Aussi bien pour contribuer à se protéger d'un état qui glisserait vers un certain autoritarisme (on ne sait pas de quoi demain sera fait), que de prestataires de paiement qui seraient tentés de revendre nos habitudes (d'achat) à des régis publicitaires, à des assurances, etc.
J'imagine que XBMC sait tirer partie du chipset graphique pour le décodage. (Parce j'imagine que le proc risque d'avoir du mal avec du 1080p).
Je serai effectivement intéressé de savoir si mplayer ou vlc savent également le faire.
Je connais mal XBMC. Est-ce que ce logiciel permet également d'enregistrer du flux vidéo en provenance d'un tuner TNT?
Il semble en effet que cela fonctionne maintenant. Mais ce n'était pas le cas encore récemment. Au point que je ne voyais pas l'intérêt d'avoir un styliste sous Impress alors qu'il ne servait à rien... Ça me gavait tellement que j'étais passé à Beamer.
Ça va peut-être me réconcilier avec ce type de logiciel de présentation.
La CNIL a un vrai pouvoir de sanction, dont elle se sert, mais qui se limite au secteur privé. Vis à vis de l'État, elle n'a qu'un avis consultatif. Et l'État souvent ne moque bien de son avis, même s'il est très critique.
Et de manière générale, la CNIL manque de moyen. Il est frappant de constater que la CNIL a un budget qui n'est pas tellement plus élevé que celui alloué à la Hadopi...
La "CNIL" allemande a un budget au moins deux fois supérieur.
Il y a bien le groupe de l'article 29, mais dont le seul pouvoir est d'émettre des avis et recommandations. Contrairement à la CNIL en France, ce groupe n'a aucun pouvoir de sanction.
C'est peut-être pas une "killer feature", mais c'est tout de même agréable.
Vu le nombre de fois où j'ai eu des problèmes de compilation, juste parce que j'avais oublié de mettre un point virgule à la fin d'une ligne...
Donc oui ça un intérêt. On peut prendre le problème à l'envers: pourquoi obliger à mettre un point virgule à la fin de chaque ligne, alors que ça ne sert à rien ?
Pour les parenthèses, je ne peux pas me prononcer pour Xtend, mais avec Scala cela permet dans certaines situations de rendre le code nettement plus lisible.
Exemple: au lieu de d = a.add(b.multiply(c)), tu peux écrire a add (b multiply c).
Et comme Scala permet d'utiliser des opérateurs pour nommer une méthode(ce n'est pas de la surcharge d'opérateur!), tu te retrouves à faire: d = a + b * c.
(À noter que la méthode * est bien prioritaire par rapport à '+' et que le résultat est bien celui auquel on s'attend).
Ah, bon?
Il me semble avoir dit au contraire que Dalvik était bien deux fois plus lent que la JVM de SUN.
Quand à la vitesse de démarrage, c'est juste une supposition, qui n'est peut-être même pas vrai.
Difficile de comparer le temps de démarrage des deux machines virtuelles sur ce plan, vu qu'elles ne tournent pas sur les mêmes architectures.
Il me semble au contraire que pas mal de choses ont été faites par SUN sur cet aspect. Peut-être pas assez (?) où trop tard.
Mais en l'état actuel je ne trouve pas qu'un programme Java lambda soit si lent que cela à se lancer... À part Eclipse, mais là c'est un peu hors norme.
Après on pourrait comparer les JME (Java version mobile) avec Dalvik. Mais dans ce cas on n'a pas de JVM officielle fournie par SUN, mais pleins de JVM différentes, avec des niveaux d'optimisation très variables.
Je ne suis pas certain que Dalvik soit si performant que cela. Déjà, jusqu'à Android 2.1, il n'y avait pas de JIT: le code était était exécuté de manière interprété et donc très lent. Depuis ils ont rajouté un JIT qui améliore certes pas mal les choses, mais je doute qu'ils arrivent au niveau de la JVM de SUN/Oracle, qui atteint des perfs qui n'ont pas à rougir face à du C. Et je dis cela pour l'avoir personnellement constaté.
À vue de nez et de certains tests perso, il manque au moins un facteur 2 avec Dalvik.
La JVM de SUN Oracle demande par contre pas mal de temps pour réellement optimiser le code. Pas terrible d'ailleurs pour les microbenchmarks.
Peut-être chez Google ont-ils particulièrement optimisé les temps de démarrage.
C'est toujours mieux en vrai, mais vu la météo actuelle et celle prévue pour ce soir par chez moi, je crois que de toute façon je serai obligé de me consoler avec Stellarium. Snif :(
Vive Stellarium donc. D'ailleurs, sous ce logiciel il est également possible de faire disparaître le plancher des vaches (une des icône en bas). Comme ça vous pouvez tricher et voir l'intégralité de l'éclipse!
Avec Celestia, ça pourrait également être intéressant.
Sachant que l'équipages d'un avion n'est pas sensé volé plus d'une certaine durée par an, justement pour ne pas dépasser un certain quota de radiations reçues, c'est effectivement très rassurant...
Ça n'est pas un problème provenant de Scala à mon avis (en tout cas pas pour les version >= 2.7).
C'est bien la première fois que j'entend parler d'un problème pour appeler des méthodes statiques depuis Scala.
Tu peux facilement faire le test avec un petit programme Scala (en appelant par exemple System.currentTimeMillis() ).
À mon avis le problème provenait plutôt du module scala de ton framework, ou d'un problème de configuration.
Pas du tout.
Il est bien évidemment possible d'appeler une méthode statique Java depuis Scala.
Et inversement, les méthodes du "compagnion object" de scala sont vues depuis Java comme des méthodes statiques classiques. Il n'y a aucun problème à ce niveau.
En ce qui concerne la compatibilité Java/Scala, il est même possible d'avoir une classe Java héritant d'une classe Scala, héritant d'une classe Java, ...
Pour autant il peut y avoir certains problèmes de compatibilité si on utilise certaines possibilités du langage Scala, qui n'ont pas d'équivalent en Java (les "traits" par exemples).
Je suis d'accord. Même s'il est possible d'extraire les sous-titres d'un fichier mkv pour les utiliser dans perroquet, ça reste un peu laborieux.
Idéalement, ça serait bien de pouvoir directement lire un DVD avec ses sous-titres. Mais là, c'est particulièrement délicat, car le format des sous-titres des DVD n'est pas un format texte. S'il faut faire de l'OCR, ça risque de devenir tout de suite plus compliqué.
En tout cas, très bon logiciel. J'ai hate d'essayer la dernière version.
En effet, jusqu'à présent, le bytecode ''Dalvik'' (nom de la machine virtuelle d'Android) était purement interprété et donc hyper lent, même si dans la plupart des cas ce n'était pas trop gênant. L'arrivée, enfin, d'un JIT est donc plutôt une bonne nouvelle.
Il existe un autre outil pour générer des panoramas, certes propriétaire, mais très efficace:
AutopanoPro (et dérivés) http://www.autopano.net/fr
Ce logiciel est multiplateforme, dont Linux PC 32 et 64 bits.
Il est beaucoup plus simple d'utilisation que Hugin, avec lequel j'ai toujours eu énormément de mal pour obtenir qqch de présentable (mais ça fait longtemps et il semblait alors particulièrement buggé).
Avec Autopano, pas besoin par exemple de sélectionner soit même des points commun entre les images. Le logiciel fait tout seul, et est même capable de scanner un répertoire pour détecter les panoramas potentiels.
Son seul défaut est d'être propriétaire...
Ceci dit, dans certaines administrations, quand ils font des appels d'offrent pour développement logiciel, ils exigent de plus en plus que cela soit (et/ou basé sur) du logiciel libre. Ça leur permet de ne plus rester dépendant d'une seule société, et ça diminue les coûts, à la fois car il n'y a plus de coûts de licence et car la concurrence est plus serrée entre les sociétés prestataires.
Je ne sais pas quelles sont exactement les administrations concernées, c'est une info de seconde main... Je ne saurai dire s'il s'agit d'une tendance générale.
Scala intégre déjà la plupart des fonctionnalités discutées pour Java7, à la différence que la version Scala est beaucoup plus puissante.
Des String dans les switch? Pfff! Scala intègre déjà cette fonctionnalitée en version survitaminée (et non limitée aux String). Et ce langage offre énormément d'autres fonctionnalités simplifiant la vie du programmeur.
Je suis conscient qu'il est important voir essentiel de faire évoluer le langage Java en lui-même. Mais pour le dev Java lambda, ça n'est peut-être pas une mauvaise idée d'envisager l'utilisation d'un langage comme Scala, qui reste compatible avec les libs Java, tout en offrant les mêmes perfs (pour généralement trois fois moins de code).
[^] # Re: C'est de ta faute
Posté par ndesmoul . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 7.
Euh, c'est un portable d'occasion… Il a pas acheté directement la licence Microsoft.
[^] # Re: CH₃COCH₃
Posté par ndesmoul . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 7.
Sinon, un chiffon imbibée d'huile (par exemple de Tournesol) sera peut-être efficace.
En tout cas ça l'est pour retirer facilement la colle d'étiquettes collées sur du verre. Évidemment ne pas trop asperger d'huile non plus, car il va falloir rincer et "dégraisser" après.
[^] # Re: FUD
Posté par ndesmoul . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 1.
Il y a d'autres solutions cryptographiques bien moins onéreuses en calcul que celles basées sur de la block chain. Elles restent centralisées par contre.
Et je parle de solutions où une carte à puce a une puissance suffisante pour faire les calculs côté client et où le commerçant n'a besoin que d'un mobile pour vérifier la transaction de manière off-line. Quand la "banque" reçoit les transactions du commerçant elle doit tout de même faire des calculs supplémentaires pour détecter des possibles cas de fraude, mais ça reste raisonnable.
Par exemple le mécanisme décrit dans ce papier: http://eprint.iacr.org/2014/785
Le consommateur est anonyme lors d'un paiement aussi bien du point de vue de la banque que du commerçant. Le commerçant par contre n'est pas anonyme, donc pas de paiement au noir.
La banque n'a techniquement la possibilité de lever l'anonymat d'un payeur qu'en cas de rejeux de certains éléments dans une autre transaction. Dans ce cas, et uniquement dans ce cas, la comparaison des deux transactions permet de lever l'anonymat.
Ce type de solution paraît offrir un bon compromis entre protection de la vie privée et lutte contre la fraude.
[^] # Re: FUD
Posté par ndesmoul . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 1.
D'un autre côté il est techniquement possible d'offrir un système de paiement électronique garantissant un certain anonymat:
Ça prendra sans doute la forme d'un système de porte-monnaie électronique rechargeable :
Précisons que bien qu'offrant un certain anonymat, ce type de système permet de détecter les fraudes et de lever l'anonymat si besoin.
Donc on peut avoir quelque chose assurant une meilleure protection de la vie privée tout en conservant la plupart des avantages du paiement électronique, y compris donc sur la détection de fraude.
C'est valable dans d'autres domaines comme les cartes de transport : il est tout à fait possible techniquement d'avoir une carte sure du point de vue du transporteur (pas de fraude), qui garantisse à l'usager qu'il ne sera pas traçable lors de ses trajets.
Il me semblerait sain de pouvoir choisir d'utiliser ce type de système, au moins pour des petits montants de tous les jours. Aussi bien pour contribuer à se protéger d'un état qui glisserait vers un certain autoritarisme (on ne sait pas de quoi demain sera fait), que de prestataires de paiement qui seraient tentés de revendre nos habitudes (d'achat) à des régis publicitaires, à des assurances, etc.
[^] # Re: quoi faire
Posté par ndesmoul . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 1.
Merci pour ton retour.
J'imagine que XBMC sait tirer partie du chipset graphique pour le décodage. (Parce j'imagine que le proc risque d'avoir du mal avec du 1080p).
Je serai effectivement intéressé de savoir si mplayer ou vlc savent également le faire.
Je connais mal XBMC. Est-ce que ce logiciel permet également d'enregistrer du flux vidéo en provenance d'un tuner TNT?
[^] # Re: quoi faire
Posté par ndesmoul . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 1.
Et est-ce que tu arrives à lire des vidéos HD avec?
Si oui avec quel lecteur?
# Siril
Posté par ndesmoul . En réponse à la dépêche L'astronomie libre sous Linux : le point fin 2012, début 2013. Évalué à 3.
Siril n'est peut-être pas abandonné. Du moins, quelqu'un semble avoir repris le projet pour le faire évoluer:
http://free-astro.vinvin.tf/index.php/Siril
[^] # Re: mouhais
Posté par ndesmoul . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 3.
Il semble en effet que cela fonctionne maintenant. Mais ce n'était pas le cas encore récemment. Au point que je ne voyais pas l'intérêt d'avoir un styliste sous Impress alors qu'il ne servait à rien... Ça me gavait tellement que j'étais passé à Beamer.
Ça va peut-être me réconcilier avec ce type de logiciel de présentation.
[^] # Re: Petite question.
Posté par ndesmoul . En réponse à la dépêche Nouvelle directive sur la protection des données personnelles : ça ne rigole plus.... Évalué à 2.
La CNIL a un vrai pouvoir de sanction, dont elle se sert, mais qui se limite au secteur privé. Vis à vis de l'État, elle n'a qu'un avis consultatif. Et l'État souvent ne moque bien de son avis, même s'il est très critique.
Et de manière générale, la CNIL manque de moyen. Il est frappant de constater que la CNIL a un budget qui n'est pas tellement plus élevé que celui alloué à la Hadopi...
La "CNIL" allemande a un budget au moins deux fois supérieur.
[^] # Re: Petite question.
Posté par ndesmoul . En réponse à la dépêche Nouvelle directive sur la protection des données personnelles : ça ne rigole plus.... Évalué à 1.
Il y a bien le groupe de l'article 29, mais dont le seul pouvoir est d'émettre des avis et recommandations. Contrairement à la CNIL en France, ce groupe n'a aucun pouvoir de sanction.
# bugbrother
Posté par ndesmoul . En réponse au journal 82 millions d'euros pour 200 caméras.... Évalué à 2.
Pour alimenter le débat, le site suivant est très instructif sur l'efficacité, ou plutôt l'inefficacité, de la vidéosurveillance :
http://bugbrother.blog.lemonde.fr/category/videosurveillance/
Je vous recommande également le site Owni qui a consacré plusieurs articles sur le sujet:
http://owni.fr/?s=vid%C3%A9osurveillance
[^] # Re: mouais
Posté par ndesmoul . En réponse à la dépêche Découvrir Xtend, un langage extension de Java. Évalué à 0.
C'est peut-être pas une "killer feature", mais c'est tout de même agréable.
Vu le nombre de fois où j'ai eu des problèmes de compilation, juste parce que j'avais oublié de mettre un point virgule à la fin d'une ligne...
Donc oui ça un intérêt. On peut prendre le problème à l'envers: pourquoi obliger à mettre un point virgule à la fin de chaque ligne, alors que ça ne sert à rien ?
Pour les parenthèses, je ne peux pas me prononcer pour Xtend, mais avec Scala cela permet dans certaines situations de rendre le code nettement plus lisible.
Exemple: au lieu de d = a.add(b.multiply(c)), tu peux écrire a add (b multiply c).
Et comme Scala permet d'utiliser des opérateurs pour nommer une méthode(ce n'est pas de la surcharge d'opérateur!), tu te retrouves à faire: d = a + b * c.
(À noter que la méthode * est bien prioritaire par rapport à '+' et que le résultat est bien celui auquel on s'attend).
[^] # Re: Java = Flash ?
Posté par ndesmoul . En réponse au journal Le java officiel est sorti de debian…. Évalué à 2.
Ah, bon?
Il me semble avoir dit au contraire que Dalvik était bien deux fois plus lent que la JVM de SUN.
Quand à la vitesse de démarrage, c'est juste une supposition, qui n'est peut-être même pas vrai.
Difficile de comparer le temps de démarrage des deux machines virtuelles sur ce plan, vu qu'elles ne tournent pas sur les mêmes architectures.
Il me semble au contraire que pas mal de choses ont été faites par SUN sur cet aspect. Peut-être pas assez (?) où trop tard.
Mais en l'état actuel je ne trouve pas qu'un programme Java lambda soit si lent que cela à se lancer... À part Eclipse, mais là c'est un peu hors norme.
Après on pourrait comparer les JME (Java version mobile) avec Dalvik. Mais dans ce cas on n'a pas de JVM officielle fournie par SUN, mais pleins de JVM différentes, avec des niveaux d'optimisation très variables.
[^] # Re: Java = Flash ?
Posté par ndesmoul . En réponse au journal Le java officiel est sorti de debian…. Évalué à 4.
Je ne suis pas certain que Dalvik soit si performant que cela. Déjà, jusqu'à Android 2.1, il n'y avait pas de JIT: le code était était exécuté de manière interprété et donc très lent. Depuis ils ont rajouté un JIT qui améliore certes pas mal les choses, mais je doute qu'ils arrivent au niveau de la JVM de SUN/Oracle, qui atteint des perfs qui n'ont pas à rougir face à du C. Et je dis cela pour l'avoir personnellement constaté.
À vue de nez et de certains tests perso, il manque au moins un facteur 2 avec Dalvik.
La JVM de
SUNOracle demande par contre pas mal de temps pour réellement optimiser le code. Pas terrible d'ailleurs pour les microbenchmarks.Peut-être chez Google ont-ils particulièrement optimisé les temps de démarrage.
# météo pourrie
Posté par ndesmoul . En réponse au journal Eclipse de cette nuit et Stellarium. Évalué à 4.
C'est toujours mieux en vrai, mais vu la météo actuelle et celle prévue pour ce soir par chez moi, je crois que de toute façon je serai obligé de me consoler avec Stellarium. Snif :(
Vive Stellarium donc. D'ailleurs, sous ce logiciel il est également possible de faire disparaître le plancher des vaches (une des icône en bas). Comme ça vous pouvez tricher et voir l'intégralité de l'éclipse!
Avec Celestia, ça pourrait également être intéressant.
# Firefox4
Posté par ndesmoul . En réponse au journal un mois avec Chrome. Évalué à 10.
Maintenant tu vas pouvoir passer à Firefox4 et nous donner tes impressions.
[^] # Re: Risques minimes?!
Posté par ndesmoul . En réponse au journal Empreinte du squelette. Évalué à 6.
m'apprendra à me relire...
# Risques minimes?!
Posté par ndesmoul . En réponse au journal Empreinte du squelette. Évalué à 10.
[^] # Re: scala <> java pas tout à fait compatibles
Posté par ndesmoul . En réponse à la dépêche Sortie de Scala 2.8 !. Évalué à 2.
C'est bien la première fois que j'entend parler d'un problème pour appeler des méthodes statiques depuis Scala.
Tu peux facilement faire le test avec un petit programme Scala (en appelant par exemple System.currentTimeMillis() ).
À mon avis le problème provenait plutôt du module scala de ton framework, ou d'un problème de configuration.
[^] # Re: scala <> java pas tout à fait compatibles
Posté par ndesmoul . En réponse à la dépêche Sortie de Scala 2.8 !. Évalué à 2.
Il est bien évidemment possible d'appeler une méthode statique Java depuis Scala.
Et inversement, les méthodes du "compagnion object" de scala sont vues depuis Java comme des méthodes statiques classiques. Il n'y a aucun problème à ce niveau.
En ce qui concerne la compatibilité Java/Scala, il est même possible d'avoir une classe Java héritant d'une classe Scala, héritant d'une classe Java, ...
Pour autant il peut y avoir certains problèmes de compatibilité si on utilise certaines possibilités du langage Scala, qui n'ont pas d'équivalent en Java (les "traits" par exemples).
[^] # Re: Fichier mkv
Posté par ndesmoul . En réponse à la dépêche Sortie de Perroquet 1.1.0. Évalué à 1.
Idéalement, ça serait bien de pouvoir directement lire un DVD avec ses sous-titres. Mais là, c'est particulièrement délicat, car le format des sous-titres des DVD n'est pas un format texte. S'il faut faire de l'OCR, ça risque de devenir tout de suite plus compliqué.
En tout cas, très bon logiciel. J'ai hate d'essayer la dernière version.
[^] # Re: Le JIT pour améliorer les performances.
Posté par ndesmoul . En réponse à la dépêche Ça bouge toujours chez Android. Évalué à 3.
# Panorama
Posté par ndesmoul . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 2.
AutopanoPro (et dérivés)
http://www.autopano.net/fr
Ce logiciel est multiplateforme, dont Linux PC 32 et 64 bits.
Il est beaucoup plus simple d'utilisation que Hugin, avec lequel j'ai toujours eu énormément de mal pour obtenir qqch de présentable (mais ça fait longtemps et il semblait alors particulièrement buggé).
Avec Autopano, pas besoin par exemple de sélectionner soit même des points commun entre les images. Le logiciel fait tout seul, et est même capable de scanner un répertoire pour détecter les panoramas potentiels.
Son seul défaut est d'être propriétaire...
[^] # Re: cela suppose une prise de conscience au niveau gouvernemental
Posté par ndesmoul . En réponse à la dépêche Les gouvernements devraient-ils s'abstenir d'externaliser les développements ?. Évalué à 1.
Je ne sais pas quelles sont exactement les administrations concernées, c'est une info de seconde main... Je ne saurai dire s'il s'agit d'une tendance générale.
# Scala
Posté par ndesmoul . En réponse au journal Le point sur Java 7. Évalué à 5.
Des String dans les switch? Pfff! Scala intègre déjà cette fonctionnalitée en version survitaminée (et non limitée aux String). Et ce langage offre énormément d'autres fonctionnalités simplifiant la vie du programmeur.
Je suis conscient qu'il est important voir essentiel de faire évoluer le langage Java en lui-même. Mais pour le dev Java lambda, ça n'est peut-être pas une mauvaise idée d'envisager l'utilisation d'un langage comme Scala, qui reste compatible avec les libs Java, tout en offrant les mêmes perfs (pour généralement trois fois moins de code).
http://www.scala-lang.org/node/25