IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Consultant informatique
    Inscrit en
    Avril 2018
    Messages
    1 548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2018
    Messages : 1 548
    Points : 125 234
    Points
    125 234
    Par défaut Alors que Java fête ses 25 ans, Oracle annonce l’arrivée de JDK 15. Cette version modernise le code existant
    Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors,
    Et supprimera le moteur JavaScript Nashorn

    Alors que la dernière version définitive du kit de développement Java (JDK) d’Oracle est sortie il y a moins d’un mois, les travaux pour la mise en œuvre de son successeur, Java 15, prévu pour le remplacer en septembre 2020, sont déjà lancés. Et jusqu'à présent, deux changements officiels - l'ajout de blocs de texte et la suppression du moteur JavaScript Nashorn - ciblent la version 15 de JDK. Tandis que trois autres propositions de changements - l'ajout de la fonctionnalité Hidden Classes, des Garbage Collectors Z et Shenandoah - sont encore en examen afin de cibler également la dernière version du JDK.

    Nom : j01.jpg
Affichages : 45525
Taille : 19,5 Ko

    Même si la page officielle de l'OpenJDK n’en parle pas encore, la page de proposition de l'OpenJDK indique que le JDK 15 est la version cible de ces propositions de changements. Les cinq propositions (si celles qui sont en examen sont validées) devraient être des fonctionnalités officielles pour le kit de développement Java (JDK) 15, qui est la base de la prochaine version de Java SE (édition standard). Voici, ci-dessous, les spécificités de ces propositions d’amélioration :

    Des blocs de texte pour une meilleure lisibilité de chaînes de caractères

    Les blocs de texte sont destinés à simplifier la tâche d'écriture des programmes Java en facilitant l'expression de chaînes de caractères couvrant plusieurs lignes de code source, tout en évitant les séquences d'échappement dans les cas courants. Un bloc de texte est une chaîne littérale de plusieurs lignes qui évite la plupart des séquences d'échappement, formate automatiquement la chaîne de manière prévisible et offre au développeur le contrôle du format lorsqu'il le souhaite.

    Les blocs de texte ont été proposés par le JEP 355 au début de 2019 et ont été ajoutés en prévisualisation au JDK 13 en juin 2019. Les réactions au JDK 13 ont suggéré qu’ils devaient demeurer en prévisualisation, avec des mises à jour, sur le JDK 14 en novembre 2019. Les commentaires sur le JDK 14 suggèrent que la fonction Text Blocks est maintenant prête à être rendue définitive et permanente, selon la page de proposition de l’OpenJDK.

    L'un des objectifs de la proposition de blocs de texte est d'améliorer la lisibilité des chaînes dans les programmes Java qui indiquent du code écrit dans des langages autres que Java. Un autre objectif est de soutenir la migration à partir de chaînes de caractères littérales en stipulant que toute nouvelle construction peut exprimer le même ensemble de chaînes de caractères qu'une chaîne littérale, interpréter les mêmes séquences d'échappement et être manipulée de la même manière qu'une chaîne littérale. Les développeurs d'OpenJDK espèrent ajouter des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle des nouvelles lignes.

    La suppression du moteur JavaScript Nashorn

    Le retrait de Nashorn, qui a fait ses débuts dans le JDK 8 en mars 2014, a depuis été rendu obsolète par des technologies telles que GraalVM. La proposition de l'OpenJDK 15 prévoit la suppression des API de Nashorn et de l'outil de ligne de commande jjs utilisé pour invoquer Nashorn. Selon la page de proposition de l’OpenJDK, le moteur, les API et l'outil avaient été dépréciés dans Java 11 avec l'intention expresse de les supprimer dans une prochaine version. Comme déjà indiqué plus haut, certaines propositions de changements sont toujours en examen, telles que :

    L’ajout de Z Garbage Collector (ZGC)

    Son intégration dans JDK 15 la ferait passer d'une fonctionnalité expérimentale à un produit définitif dans le cadre de cette proposition. Arrivé par le JEP 333 et intégré dans le JDK 11, qui est arrivé en septembre 2018, le ZGC est un Collector évolutif et à faible latence, d’après la page de proposition. Le ZGC a été introduit à titre expérimental à l’époque parce que les développeurs de Java ont décidé qu'une fonctionnalité de cette taille et de cette complexité devait être introduite avec précaution et de manière progressive.

    Depuis lors, un certain nombre d'améliorations ont été ajoutées, allant du déchargement simultané des classes, du désengagement de la mémoire inutilisée et de la prise en charge du partage des classes de données à une meilleure sensibilisation à NUMA et au pré-touchement de tas multi-thread. De plus, la taille maximale du tas a été augmentée de quatre téraoctets à 16 téraoctets. Les plateformes prises en charge par ce changement, selon la page de proposition, sont Linux, Windows et MacOS.

    L’ajout du Garbage Collector Shenandoah

    L’ajout du Garbage Collector Shenandoah à faible temps de pause dans le cadre de cette proposition ferait de cette fonctionnalité un élément de production et sortirait du stade expérimental. Le GC Shenandoah a été intégré au JDK 12 par le JEP 189. Il a été marqué comme expérimental afin de correspondre au statut d'autres nouveaux GC, notamment les GC Epsilon et ZGC. Aujourd'hui, Shenandoah est prête à abandonner son statut expérimental dans les principaux JDK.

    L’ajout des Hidden Classes

    Les Hidden Classes sont des classes qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. Ces fonctionnalités, qui seront introduites dans Java 15, sont destinées à être utilisées par des frameworks qui génèrent des classes à l'exécution et les utilisent indirectement. Une Hidden Class peut être définie comme un membre d'une niche de contrôle d'accès et peut être déchargée indépendamment des autres classes.

    L’ajout de cette fonctionnalité a été motivé, entre autres, par le fait que de nombreuses implémentations de langage construites sur la JVM reposent sur la génération dynamique de classes pour plus de flexibilité et d'efficacité, d’après la page de proposition. « Par exemple, dans le cas du langage Java, javac ne traduit pas une expression lambda dans un fichier de classe dédié au moment de la compilation mais, au contraire, émet un bytecode qui génère et instancie dynamiquement une classe pour produire un objet correspondant à l'expression lambda lorsque cela est nécessaire », lit-on sur la page.

    Les premières versions builds du JDK 15 sont disponibles à l'adresse java.jdk.net. Le JDK 15 aura le statut de version de fonctionnalité à court terme, elle sera donc supportée pendant six mois, soit jusqu’en mars 2021, selon la cadence de livraison dite « non-LTS » d'Oracle. La prochaine version de support à long terme (LTS), qui bénéficiera de plusieurs années de support, sera la version JDK 17, prévue pour septembre 2021.

    Source : OpenJDK

    Et vous ?

    Que pensez-vous de ces propositions de fonctionnalités officielles pour Java 15 ?

    Lire aussi

    Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
    JDK 14 va apporter plus de fonctionnalités que les deux versions précédentes combinées, petit tour d'horizon sur celles qui sont susceptibles d'intéresser le plus les développeurs
    Le JDK 9 va supporter la compilation anticipée (AOT), en commençant par les systèmes Linux 64-bit exécutant Java 64-bit

  2. #2
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 913
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 913
    Points : 206 597
    Points
    206 597
    Par défaut Alors que Java fête ses 25 ans, Oracle annonce l’arrivée de JDK 15. Cette version modernise le code existant
    Alors que Java fête ses 25 ans, Oracle annonce l’arrivée de JDK 15. Cette version modernise le code existant
    et s'accompagne de la suppression du moteur JavaScript Nashorn

    Oracle a annoncé la disponibilité générale de Java 15 lors du discours d'ouverture de sa conférence Developer Live, la version en ligne des événements annuels CodeOne et OpenWorld de la société.

    Le dernier kit de développement Java (JDK) offre de nouvelles fonctionnalités, certaines fonctionnalités en préversion désormais finalisées, des modules d'incubation (qui peuvent s'apparenter à des fonctionnalités expérimentales), la modernisation continue du code existant, une multitude de corrections de bogues et la dépréciation des fonctionnalités obsolètes.

    Cette version intervient alors que Java fête ses 25 ans, a noté Georges Saab, vice-président du développement d'Oracle Java Platform Group, dans un communiqué.

    « Alors que Java célèbre son 25e anniversaire, nous continuons à faire des investissements techniques qui font avancer l'innovation Java et contribuent à faire face à l'évolution rapide du paysage technologique », a déclaré Saab. « La disponibilité de Java 15 et l'innovation incrémentielle qui accompagne le passage à une cadence de publication de six mois donnent à la communauté Java les outils dont elle a besoin pour créer des applications modernes qui font avancer notre monde ».

    Une correction de bogue sur quatre provient de développeurs tiers

    Java 15 a été lancé avec la cadence de publication Java de six mois désormais bien établie, lancée par Oracle avec la version Java 10 en 2018. Il s'agit de la sixième version depuis l'annonce de la nouvelle cadence.

    « Au lieu de rendre des dizaines de milliers de correctifs et une centaine de propositions d'amélioration JDK (JEP) disponibles dans une version majeure toutes les quelques années », a observé Sharat Chander, directeur de la gestion des produits Java SE chez Oracle, dans un billet de blog, « les améliorations sont livrées sous forme de versions de fonctionnalités plus petites selon un calendrier de six mois plus gérable et prévisible. Ces modifications peuvent aller d'une fonctionnalité importante à de petites améliorations, en passant par la maintenance de routine, les corrections de bogues et les améliorations de la documentation. Chaque modification est représentée dans un seul commit pour un seul problème dans le système de bogues JDK ».

    « Sur les 2 136 problèmes JIRA marqués comme résolus dans Java 15, 1 702 ont été résolus par des personnes travaillant pour Oracle, tandis que 434 ont été apportés par des développeurs individuels et des développeurs travaillant pour d'autres organisations », a noté Chander.

    « Oracle tient à remercier les développeurs travaillant pour des organisations comme ARM, Amazon, IBM, Intel, NTT Data, Red Hat, SAP et Tencent pour leurs contributions notables. Nous sommes également reconnaissants de voir les contributions de petites organisations telles que Ampere Computing, Bellsoft, Longsoon et des développeurs indépendants qui ont collectivement contribué à 3 % des correctifs de Java 15. Et, enfin et surtout, nous aimerions remercier les premières contributions de DataDog et Microsoft ».

    La version Java 15 est le résultat d'un développement à l'échelle de l'industrie impliquant des révisions ouvertes, des versions hebdomadaires et une collaboration approfondie entre les ingénieurs Oracle et les membres de la communauté mondiale des développeurs Java via la communauté OpenJDK et le processus de communauté Java.

    Nom : oracle.png
Affichages : 32805
Taille : 29,8 Ko

    Nouveautés et améliorations dans Java 15

    Java 15 s’accompagne de quatorze améliorations / modifications principales, dont un module d'incubation (qui peuvent s'apparenter à des fonctionnalités expérimentales), trois fonctionnalités en préversion, deux fonctionnalités obsolètes et deux suppressions.

    Certaines améliorations sont introduites dans les modules Incubator, un moyen de mettre les API non finales et les outils non finaux entre les mains des développeurs, leur permettant d'offrir des commentaires qui peuvent à terme améliorer la qualité de la plateforme Java.

    De même, certaines améliorations sont introduites en tant que fonctionnalités en préversion, qui sont des fonctionnalités de langage ou de machine virtuelle de la plateforme Java SE entièrement spécifiées, entièrement implémentées et pourtant non permanentes.

    Enfin, certaines modifications visent à réduire la taille et la portée du JDK via la dépréciation. La dépréciation encourage les applications à s'éloigner de l'API, décourage les applications de former de nouvelles dépendances sur l'API et informe les développeurs des risques d'une dépendance continue à l'égard de l'API. Avec l'outil jdeprscan, introduit pour la première fois dans Java 9, les utilisateurs peuvent effectuer une analyse statique de leurs fichiers jar (ou une autre agrégation de fichiers de classe) pour identifier les utilisations d'éléments d'API obsolètes, leur permettant ainsi de se préparer à l'avance pour leur suppression future.

    Nouvelles fonctionnalités

    Algorithme de signature numérique Edwards-Curve

    Cette fonctionnalité améliore la sécurité et les performances en implémentant des signatures cryptographiques à l'aide de l'algorithme de signature numérique Edwards-Curve (EdDSA) tel que décrit par la RFC 8032. EdDSA est un schéma de signature de courbe elliptique moderne qui présente plusieurs avantages par rapport aux schémas de signature existants dans le JDK. L'objectif principal de ce JEP est une implémentation de ce schéma tel que normalisé dans la RFC 8032. Ce nouveau schéma de signature ne remplace pas l'ECDSA.

    L’ajout des Hidden Classes

    Les Hidden Classes sont des classes qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. Elles sont destinées à être utilisées par des frameworks qui génèrent des classes à l'exécution et les utilisent indirectement. Une Hidden Class peut être définie comme un membre d'une niche de contrôle d'accès et peut être déchargée indépendamment des autres classes.

    L’ajout de cette fonctionnalité a été motivé, entre autres, par le fait que de nombreuses implémentations de langage construites sur la JVM reposent sur la génération dynamique de classes pour plus de flexibilité et d'efficacité, d’après la page de proposition. « Par exemple, dans le cas du langage Java, javac ne traduit pas une expression lambda dans un fichier de classe dédié au moment de la compilation mais, au contraire, émet un bytecode qui génère et instancie dynamiquement une classe pour produire un objet correspondant à l'expression lambda lorsque cela est nécessaire », lit-on sur la page.

    Modernisation du code existant

    Réimplémentation de l'ancienne API Datagram Socket

    Cette fonctionnalité améliore la maintenabilité et la stabilité du JDK en remplaçant les implémentations sous-jacentes des API java.net.DatagramSocket et java.net.MulticastSocket par des implémentations plus simples et plus modernes. Les nouvelles implémentations seront faciles à adapter pour fonctionner avec des threads virtuels, actuellement explorées dans Project Loom.

    Nom : JEP.png
Affichages : 3635
Taille : 39,9 Ko

    Preview et fonctionnalités expérimentales qui sont maintenant finalisées

    ZGC: un GC évolutif à faible latence

    ZGC a été intégré dans JDK 11 par JEP 333, dans le but d'améliorer la productivité en réduisant les temps de pause GC, de gérer des tas allant de relativement petits (quelques centaines de mégaoctets) à très grands (plusieurs téraoctets), ainsi que de poser un base pour les futures fonctionnalités et optimisations du GC utilisant des pointeurs et des barrières de charge colorés. Avec JEP 377, ZGC passe de la catégorie de fonctionnalité expérimentale à fonctionnalité de production.

    Blocs de texte pour une meilleure lisibilité de chaînes de caractères

    Les blocs de texte sont destinés à simplifier la tâche d'écriture des programmes Java en facilitant l'expression de chaînes de caractères couvrant plusieurs lignes de code source, tout en évitant les séquences d'échappement dans les cas courants. Un bloc de texte est une chaîne littérale de plusieurs lignes qui évite la plupart des séquences d'échappement, formate automatiquement la chaîne de manière prévisible et offre au développeur le contrôle du format lorsqu'il le souhaite.

    Les blocs de texte ont été proposés par le JEP 355 au début de 2019 et ont été ajoutés en prévisualisation au JDK 13 en juin 2019. Les réactions au JDK 13 ont suggéré qu’ils devaient demeurer en prévisualisation, avec des mises à jour, sur le JDK 14 en novembre 2019. Les commentaires sur le JDK 14 suggèrent que la fonction Text Blocks est maintenant prête à être rendue définitive et permanente, selon la page de proposition de l’OpenJDK.

    L'un des objectifs de la proposition de blocs de texte est d'améliorer la lisibilité des chaînes dans les programmes Java qui indiquent du code écrit dans des langages autres que Java. Un autre objectif est de soutenir la migration à partir de chaînes de caractères littérales en stipulant que toute nouvelle construction peut exprimer le même ensemble de chaînes de caractères qu'une chaîne littérale, interpréter les mêmes séquences d'échappement et être manipulée de la même manière qu'une chaîne littérale. Les développeurs d'OpenJDK espèrent ajouter des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle des nouvelles lignes.

    Shenandoah

    Shenandoah a été intégré dans JDK 12 par JEP 189. Il a été marqué comme expérimental afin de correspondre au statut d'autres nouveaux GC, notamment Epsilon GC et ZGC. JEP 379 fait passer récupérateur de mémoire Shenandoah d'une fonctionnalité expérimentale à une fonctionnalité de production mais ne propose pas de changer le GC par défaut, qui reste G1, et ne propose pas de changer le processus de développement de Shenandoah, qui continuera à prendre en charge les dernières JDK et JDK LTS / STS populaires.

    Fonctionnalités d'incubation et en Preview

    Classes Sealed (Preview 1)

    Cette fonction en préversion améliore la productivité des développeurs en améliorant la programmation Java avec des classes et des interfaces Sealed, ce qui permet à l'auteur d'une classe ou d'une interface de contrôler quel code est responsable de son implémentation, fournit un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation d'un superclasse et soutiennent les orientations futures de la correspondance de modèles en étayant l'analyse exhaustive des modèles.

    Pattern Matching pour instanceof (Preview 2)

    Cette fonction en Preview, qui a été introduite pour la première fois dans JEP 305 dans le cadre de JDK 14, améliore la productivité des développeurs en éliminant le besoin d'un code boilerplate et devrait permettre un code sécurisé de type plus concis.

    Records (Preview 2)

    Records améliore la productivité des développeurs en fournissant une syntaxe compacte pour déclarer des classes qui agissent comme des supports transparents pour les données immuables. Les Records ont été proposés par JEP 359 à la mi-2019 et livrés en tant que fonctionnalité en préversion dans JDK 14. Ce JEP propose de revoir la fonctionnalité dans JDK 15, à la fois pour incorporer des améliorations basées sur les commentaires et pour prendre en charge des formes supplémentaires de classes et d'interfaces locales dans le langage Java.

    API Foreign-Memory Access (Incubator 2)

    L'API Foreign-Memory Access a été proposée par JEP 370 et ciblée sur JDK 14 fin 2019 en tant qu'API d'incubation. Ce JEP propose d'incorporer des raffinements basés sur les commentaires et de réincuber l'API dans JDK 15. Cette fonctionnalité d'incubation définit une API pour permettre aux programmes Java d'accéder en toute sécurité et efficacement à la mémoire étrangère en dehors du tas Java.

    Dépréciations et suppressions

    Comme avec les versions de fonctionnalités précédentes, JDK 15 rend certaines fonctionnalités obsolètes et supprime les fonctionnalités précédemment obsolètes

    Activation RMI obsolète, il sera supprimé dans une version future

    JEP 385 déprécie le mécanisme d'activation RMI qui sera supprimé dans une version future. L'activation RMI est une partie obsolète de RMI qui est facultative depuis Java 8. Aucune autre partie de RMI ne sera obsolète.

    Suppression du moteur JavaScript Nashorn

    JEP 372 supprime le moteur de script et les API JavaScript Nashorn, ainsi que l'outil jjs. Le moteur, les API et l'outil ont été déconseillés pour suppression dans JDK 11 avec l'intention expresse de les supprimer dans une version ultérieure.

    Suppression des ports Solaris et SPARC

    JEP 381 supprime le code source et la prise en charge de build pour les ports Solaris / SPARC, Solaris / x64 et Linux / SPARC. Ces ports ont été marqués comme obsolète dans JDK 14 avec l'intention expresse de les supprimer dans une version ultérieure.

    OpenJDK (JDK 15)

    Sources : note de version, annonce Oracle, Sharat Chander (Oracle)

    Voir aussi :

    Voici comment la startup Diffblue utilise l'IA pour automatiser les tests unitaires pour les applications Java à travers son outil dénommé "Diffblue Cover"
    C++ était le langage de programmation à la croissance la plus rapide en septembre selon TIOBE, Java a enregistré la plus forte baisse mais reste en seconde position
    La version open source du kit de développement Java (OpenJDK) débarque sur Windows 10 pour l'architecture ARM 64 bits au travers d'un projet de portage initié par Microsoft
    Red Hat publie Mandrel, une distribution Java qui compile les applications Java directement en code machine natif pour un démarrage plus rapide en utilisant moins de mémoire

  3. #3
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 860
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 860
    Points : 22 900
    Points
    22 900
    Billets dans le blog
    51
    Par défaut
    Les contributeurs de Tencent ? Ils ont pas peur des retours de la Maison Blanche ?

    Hum, du coup c'est pas bien clair, mais suite au retrait de Nashorn, il n'est plus possible de faire tourner du JavaScript sur la JVM en standard ? Il faut utiliser une lib tierce implémentant le scripting engine (JSR-223) pour JavaScript ?

    Quels sont les changements de syntaxe apporte sur instanceof et Record par rapport au JDK 14 ?

    Ça fait longtemps que je ne suis plus l’actualité des UNIX mais dois-je en déduire que Solaris c'est définitivement fini, Oracle l'a jeté a la poubelle ?

    A noter que JavaFX 15 est sorti il y a 2 jours pour accompagner le lancement de ce nouveau JDK.

  4. #4
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2019
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2019
    Messages : 6
    Points : 49
    Points
    49
    Par défaut
    Citation Envoyé par bouye Voir le message
    Hum, du coup c'est pas bien clair, mais suite au retrait de Nashorn, il n'est plus possible de faire tourner du JavaScript sur la JVM en standard ? Il faut utiliser une lib tierce implémentant le scripting engine (JSR-223) pour JavaScript ?
    En réalité, la fonctionnalité est toujours là : le moteur Nashorn est simplement remplacé par GraalVM.
    L'avantage est qu'on ne sera plus limité à utiliser de l'ECMAScript 5.1 car GraalVM supporte déjà ECMAScript 2019 et une bonne partie d'ECMAScript 2020.

    Sinon, il y a très peu de changement à prévoir dans le code, ça se limitera à remplacer le nom du moteur dans la méthode .

Discussions similaires

  1. Réponses: 5
    Dernier message: 08/11/2018, 13h23
  2. Remettre sur les rails un projet Java EE complexe
    Par User Name dans le forum Tomcat et TomEE
    Réponses: 15
    Dernier message: 24/10/2013, 18h22
  3. KDE SC 4.4 est arrivé, KDE 4.5 déjà sur les rails (et en vidéo)
    Par Gordon Fowler dans le forum Actualités
    Réponses: 19
    Dernier message: 13/02/2010, 02h02
  4. Réponses: 1
    Dernier message: 09/12/2009, 11h29
  5. comment savoir qui est connecté sur les db
    Par zoltix dans le forum Requêtes
    Réponses: 4
    Dernier message: 19/05/2006, 16h35

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