boubou a écrit 1384 commentaires

Je vois mal comment garder de manière confortable la compatibilité avec C dans ces conditions. Et ce que tu appelles un "cas marginal" est en fait l'une des raisons du succès de C++.

Et bien simplement quand tu déclares un objet qui doit être compatible C, tu le déclares final ou un mot clé avoisinant. C'est franchement pas compliqué et ça éviter d'avoir à penser au virtuel quand on fait de la vraie programmation objet.

Il n'y a aucun rapport ici avec l'analyse du code. L'intérêt de l'analyse statique, c'est de pouvoir faire de l'inlining de méthodes, même quand elles sont virtuelles. Encore une fois, le mécanisme du C++ aurait pu permettre d'optimiser à la main (solution de merde mais effectivement presque indispensable à l'époque) tout en prenant le système inverse (par défaut non optimiser et donc virtuel, sur demande non virtuel).

C'est toujours facile de dire "ça c'est une connerie" quand on arrive 15 ans après la bataille.

J'aurais du mal à te démontrer la chose, mais en tout cas en 92 déjà, certains de mes amis spécialistes des langages de programmation (caml etc.) disais déjà que l'idée du virtuel était complètement débile et surtout construite à l'envers.

Je serais plutôt du coté de Stroustrup, quand il dit que le gros loupé de C++ c'est de ne pas avoir rapidement fourni une lib standard complète.

Ca, c'est ce qui provoquera la mort de C++ dans les années à venir...

C'est du WEB, et WEB, c'est du pascal, cf http://www.tex.ac.uk/cgi-bin/texfaq2html?label=webpkgs(...)

Et bien entendu, ça n'a jamais permis de prouver que TeX était sans bug, cf http://www.tug.org/whatis.html(...)

Euh, d'abord quel besoin d'être agressif et grossier ?

Ok, désolé. Cependant, ça devient insupportable de répondre toujours au même FUD. Donc toutes mes excuses pour l'aggressivité, pas pour le qualitificatif "conneries pareilles".

mais ce n'est pas du logiciel libre tout d'abord

C'est sûr que le site de la SNCF n'est pas libre, mais bon, on s'en fout un peu. Par contre, ce qui est plus remarquable, c'est que Chronopost utilise en partie JBoss.

des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.

C'est de l'humour ? Le matériel de pointe en question, ce sont surtout les 4Go de mémoire par serveur, à part ça, je te fais remarquer que ce qui coûte cher, ce n'est pas le matériel, mais les programmeurs. Et vu l'efficacité pour le développement de framework comme .Net ou J2EE, la boite gagne. Quand nous avons remporté l'appel d'offre, tout était bien entendu pris en compte, les serveurs comme le coût de développement. Tient d'ailleurs, j'ai oublié de dire que notre solution est entrièrement basée sur de l'open source, excepté la JVM...

Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main

Sauf que c'est du pipot intégral. Je connais les benchs, ils sont réalisé contre l'implémentation basique toute pourrie de BLAS et LAPAC, pas contre une implémentation haut de gamme comme la MKL d'Intel ou Atlas (open source). Par contre, les benchs dont je te parlais sont deux de COLT contre MKL et Atlas... Alors oui, Blitz c'est sympa, mais c'est un gadget pour faire du calcul matriciel efficace, contrairement à COLT. Bien sûr, tu peux vraisemblablement utiliser Blitz au dessus d'une implémentation efficace de BLAS, mais c'est aussi possible en Java. L'intérêt de COLT, c'est que c'est 100% pur Java.

je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.

En effet, comme en Sather, et dans une certaine mesure. Sauf qu'à ma connaissance, la décision d'inlining est prise en se basant sur des critères heuristiques de complexité de la méthode, alors qu'avec un JIT, tu peux faire des évaluations par chronométrage. De plus, dès que l'analyse globale laisse un doute (à cause de la covariance en Eiffel, par exemple), tu ne peux plus inliner. Avec un JIT, on peut imaginer maintenir deux codes, une version inlinée parce qu'en général on doit utiliser celle-ci et une version sans inline quand on détecte (par un simple test de plus) qu'en fait l'objet passé n'est pas du bon type.

Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.

Bien entendu, mais les machines virtuelles compilent le code au vol. Pour une application qui tourne longtemps, elles peuvent battre la compilation statique...

Oué enfin voilà quoi : y'a encore des trucs propiétaires... le problème est toujours présent...

En effet, je ne dis pas le contraire. Mais lire que l'implémentation n'est pas du tout libre, c'est pénible parce que c'est faux.

et reste que le Java a des lacunes : impossible de gérer les pointeurs : "Sécurité" !! oui mais des fois c bien pratique : c bizzare, quand j'essai en C# (sous ms.NET) de manipuler les pixel d'une image avec les routines dispo, je vais environ 40 fois plus vite avec un accès direct par pointeur...

Je ne comprends rien à ton post. Tu parles de java ou de C# ? Si les routines de manipulation d'image en C# sont mauvaises, je ne vois le rapport 1) avec les pointeurs, 2) avec Java. En Java, la version 1.4 a apporté beaucoup de nouvelles choses pour la manipulation des images et tu peux bien sûr les manipuler pixels par pixels de façon très efficace, en accédant directement au raster.

Le lien que tu fais entre pointeurs et efficacité me semble tout à fait hasardeux, soit dit en passant...

Franchement, je ne pense pas. Certaines idées sont très bonnes, d'autres sont des reculs par rapport à Java (par exemple les méthodes virtuelles ou les sections unsafe (je ne me rappelle plus le nom exact)). Il existe effectivement certaines différences basiques qui simplifient la vie en C#, en particulier la gestion des énumérations (grosse lacune de Java) et l'autoboxing des types fondamentaux, deux éléments qui vont être ajoutés dans le jdk 1.5. Même chose pour le foreach. Le switch de C# est mieux foutu que celui de Java et risque de le rester, par contre le jdk 1.5 apportera les génériques, peut être plus vite qu'en C#.

Ceci étant, comme je n'ai de C# qu'une connaissance académique, car je n'ai jamais rien développé avec, tu as peut être raison pour la mise en oeuvre réelle. Toutes mes excuses pour mettre un peu embalé. Il faut dire que ton .net mieux conçu que J2EE, là, j'ai plus de doute...

C'était nécéssaire pour garder la compatibilité avec C.

Vrai et faux. Il aurait fallu faire exactement le contraire, à savoir par défaut virtuelle, et optionnellement non virtuelle, comme en Java (et en Sather, mais avec un mécanisme plus complexe). Le problème est que C++ est encombré par des "optimisations" stupides qui sont effectivement intéressantes pour certains cas particuliers marginaux (le fait de pouvoir transformer un objet en struct pour pouvoir le passer à du C) mais qui pourissent le cas général. Cette idée du virtuel est vraiment la plus stupide de C++, alors que la volonté d'être compatible avec le C pouvait se résoudre dans l'autre sens. Quelle misère... Mais nous avons déjà eu cette discussion il y a quelques années, mon cher Guillaume.

Et si les premiers compilos C++ avaient du implémenter une analyse globale du code pour optimiser ça, on s'en serait jamais sorti.

Ca je veux bien le croire. Mais bon, les templates sont tellement délirants en C++ qu'il a fallut des années pour découvrir ce qu'on pouvait faire avec (les expressions templates, par exemple) et aussi des années pour les implémenter correctement (est-ce le cas d'ailleurs).

Par ailleurs, en C# les méthodes ne sont pas virtuelles par défaut. Je ne me souviens plus exactement pourquoi... une limitation de leur runtime, quelque chose dans ce genre.

Une sacrée connerie du C#, si tu veux mon avis.

Eh oui, il faut voir les choses en face, Java est propriétaire. Ok, la
spécification est publique, mais l'implémentation ne l'est pas du tout.

Putain, mais c'est incroyable de continuer à lire des conneries pareilles. Une grande partie de l'implémentation de Java est libre, point final. Par exemple, toute la partie XML du jdk 1.4 (versions se et ee) vient du projet apache. C'est très clairement indiqué dans la doc et la licence. Il s'agit de l'implémentation de référence, pas d'un clonage. De même, la meilleure implémentation des web services en Java (les api JAXRPC, entre autres) est clairement Axis qui est en avance sur Sun sur ce point. L'implémentation de référence des JSP et servlets est Tomcat, logiciel open source du groupe apache ! La spécification J2EE 1.4 est en cours d'implémentation par deux projets open source, JBoss et JOnAS qui implémentent déjà l'intégralité de J2EE 1.3, c'est-à-dire l'ensemble des api ajoutées à l'édition standard. La partie graphique spécifique au système du jdk 1.4 passe sous unix de motif à GTK dans l'implémentation de référence.

Mais Java a ses gros défauts. C'est un glouton de mémoire, c'est parfois
très lent et surtout... ce n'est pas utilisé dans la "vraie vie" !!

Sort de ton trou ! Ce n'est pas un répétant une connerie qu'elle devient vraie. Le site web de la SNCF est en Java (EJB), celui de Chronopost aussi. Les exemples sont légions. Et je ne parle pas simplement de la partie présentation (JSP servlet), mais bien sûr de la partie métier et de l'interfaçage avec les gros systèmes qui tournent derrière. Sur le serveur, Java est utilisé massivement. Autre exemple, j'ai participé à un appel d'offre gagné par une entreprise pour refaire le système de billeterie de la fnac (fance billet et billetel), le plus gros système de ce genre en France, et devine quoi, on va le faire en JAVA !!!!


Ah oui, il faudrait que cette plateforme soit "native" (i.e. *pas*
basée sur une machine virtuelle) pour offrir les performances que
l'on attends des logiciels "qui marchent".

C'est marrant les gens qui se la petent avec Eiffel super bien conçu, etc. et qui ensuite font "table rase" des énormes progrès réalisés par les machines virtuelles. Les machines virtuelles avec leur JIT offrent des performances excellentes, souvent meilleures que le code compilé. Elles peuvent en effet réaliser des optimisations basées sur le profil d'utilisation d'une méthode, chose impossible à faire sans VM, comme par exemple un inlining de méthode quand le besoin s'en fait sentir. De plus, le byte code extrêmement contrôlé permet des optimisations et une adaptation au hardware. Il est remarquable de voir que pour du calcul matriciel par exemple, la JVM d'IBM est capable d'obtenir des performances environ 2 fois inférieures à celle de la bibliothèque MKL d'intel implémentée en assembleur et adaptée à l'architecture physique de chaque CPU (en particulier la taille du cache). Par rapport à une implémentation naïve de calcul matriciel (en C ou C++), une bibliothèque évoluée comme COLT peut être 300 fois plus rapide, grâce aux algorithmes utilisés, mais aussi grâce à l'excellence de la JVM d'IBM, qui est capable par exemple de supprimer au vol les tests de débordement d'un tableau quand le prouveur de byte-code intégré démontre que les tests sont inutiles.

.NET, c'est un Framework (mieux pensé que celui de java)

Affligeant. C'est quoi ton argument ? Parce que tu sais beaucoup de gens pensent exactement le contraire ?

un langage (plus agréable que java dans l'exercice),

C'est le même langage ! Les différences entre C# et Java sont plus que minimies, je dirais même pas 10%. Qualifier C# de plus agréable est grotesque.

une machine virtuelle (avec JIT).

Pourquoi, il n'y a pas de JIT dans les JVM Java ?

Mais il y a aussi d'autres langages au dessus du Framework
comme Python ou Cobol, ou C++, ou VB.

Formidable. Il y a littéralement des centaines de langages qui tournent sur la JVM Java.

Sur les méthodes virtuelles, une grosse bouse du C++, ça fait des années qu'on sait que la meilleure méthode, c'est de les virer à la compilation, par une analyse globale du code (cf Sather et Eiffel). Je soupçonne la machine virtuelle d'IBM de faire ça en just in time. Le vrai problème d'ailleurs ne vient pas du passage par un pointeur qui ne coûte pas grande chose, mais plutôt de ne pas pouvoir inliner la méthode et donc d'être obliger de faire un appel. D'ailleurs tu parles de ça dans la suite de ton post ! Le garbage collector est probablement plus lent qu'un système de déallocation explicite comme en C++ Faux. De nombreuses études démontrent le contraire, en particulier grâce au désallocation par bloc impossibles à faire en C++.

Et si Sun One Studio n'était pas bien programmé ? Quel produit te propose les mêmes fonctionnalités, mais implémentées dans un autre langage ?

JBoss, Tomcat et tous les outils XML que j'utilise (en particulier le moteur xslt), ainsi que ant. Je remplace progressivement des outils très pénibles comme make par des outils beaucoup plus souples comme ant. Bien entendu, mon OS est écrit en C, comme mon navigateur et lecteur de mail. De plus, mon éditeur de texte (emacs) est écrit en C et lisp (horrible langage très lent, n'est-ce pas ?), alors que mon formatteur de document (TeX) est écrit en pascal (horrible, n'est-ce pas). Je connais de nombreuses personnes qui ont déjà remplacé emacs par jedit, et d'autres qui ne jurent que par eclipse. Pour l'instant, je me tate, mais c'est pour bientôt, je pense.

Juste quelques questions et remarques, vu que ça fait bien longtemps que je n'ai pas programmé en Ada et donc que je ne connais pas bien la version 95. Pour la productivité, les programmes non buggués, etc. il y a aussi de nombreuses études qui montrent que Java explose C++ et C, et je t'avoue que je ne suis pas super convaincu. J'ai vu chez Thomson (oups Thales) de bons ingénieurs bosser en Ada et en C++, et franchement, ce qui faisait la différence avec les nazes, c'était plus les méthodes travails que le langage. Sinon, et c'est la partie question, tu parles de la pauvreté de Java comparé à Ada, et la, je suis très très dubitatif. En effet, Ada contient deux choses très intéressantes, la notion de "templates" en bien mieux que les templates du C++ et la notion de contraintes sur les types (du genre un nouveau type int compris entre 0 et 100). Pour les templates, tu auras ça en Java 1.5, avec du F-bound polymorphisme qui, à ma connaissance, explose ce qui existe en Ada (mais bon, comme je le disais plus haut, je ne connais pas bien Ada 95). Pour les contraintes sur les types, il suffit de définir une classe (ok, c'est plus lourd qu'en Ada). Par contre, il existe de nombreuses choses en Java qui n'existent pas (à ma connaissance) en Ada. Je pense en particulier à tout l'aspect dynamique lié au chargeurs de classes, à l'introspection (les proxy dynamiques, quel pied), l'architecture de sécurité. Bref, je pense que les langages sont difficilement comparables en terme de fonctionnalité.

au gaspillage de ressources pur et simple. Vraisemblablement. Cependant, la vrai différence entre les deus machines virtuelles, c'est essentiellement le passage par adresse possible pour les types fondamentaux dans celle de MS et pas dans la JVM. Il est donc probable que pour des langages qui utilisent cette fonctionnalité, la version MS soit plus rapide que la version JVM (ça a été démontré pour pascal, par exemple). Sinon, je ne comprends rien à ton passage sur le JIT. Les deux VM ont des JIT, celui de la JVM est très performant, donc je ne vois pas trop le problème.

D'après certains experts, VB.Net est tellement différent de VB standard, qu'il serait plus productif de passer directement à C#, ce qui confirmerait les posts plus haut qui indiquaient que le vrai langage .Net, c'est C#

Pour meriter cette appelation ils ont fait quoi ?

Laisse tomber, c'est Jar Jar. En général, les discussions avec lui finissent par "coin coin".

Les gens sont vraiment cons alors, pourquoi ne codent-ils pas en Java ?

C'est ce qu'ils font. Sors la tête de ton trou, va faire un tour sur theserverside ou d'autres endroits sympa et tu verras que Java est un des langages les plus utilisés actuellement.

Parce que c'est lent

Affirmation grotesque. Sur certains benchs, Java est plus rapide que C++ ou que C.

incompatible d'une version à l'autre

Compatible ascendant, c'est normal, ça s'appelle les progres.

d'une plateforme à l'autre

N'importe quoi. Tout problème de compatibilité est un bug et franchement, il y a en pas plus que dans tout autre logiciel de la même taille.

Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...

Parce qu'ils sont vieux.

ssssssssplendide logiciel propriétaire jusqu'aux orteils qu'est Java

Java n'est pas propriétaire, il est développé par un comité tout aussi ouvert que le consortium X l'était par exemple. La fondation apache participe régulièrement aux définitions (les JSR) qui font avancer la plate-forme. Certains éléments de celle-ci sont implémentés en open source, comme par exemple le moteur de référence (dixit Sun) JSP/Servlet (à savoir Tomcat). De même, la partie J2EE existe sous forme de deux implémentations open source (JOnAS et JBoss). Sun a pris position de façon officielle sur le support des développeurs open source en Java et sur la possibilité d'implémenter les specs en open source. De plus, classpath (projet GNU officiel), gcj, etc. implémentent (de façon incomplète, certe) en open source une grande partie de l'api Java, le seul élément qui manque encore pour que Java soit complètement open source. Parce comme tu racontes n'importe quoi, tu ne sais sûrement pas que le meilleur compilateur Java (à saoivr jikes) est open source et qu'il existe de nombreuses machines virtuelles open source qui fonctionnent plutôt bien (kaffe, Japhar, etc.).

Avant de dire des conneries, renseigne toi. Si le reste de ton propos comprend autant de bêtises que le début de ta première phrase, on n'est pas arrivé...

Si, si, mais celui-la, justement, il était velu mais pas si bô que ça, je trouve. Je préfère quand on "discute" des mérites comparés de Java et de C#, ou encore de Mandrake et de RedHat, ou, peut être mon préféré, de GNU/Linux ou de Linux...

Il nous manque, hein, le -1...

C'est quand même incroyable de lire encore ce genre de troll à deux centimes (de francs). Par dela le troll, dans les réponses qu'il a engendrées, il est fascinant de voir comment on oublie rapidement les intérêts de (La)TeX pour le défendre face à XML.

Bien entendu, le rendu final de TeX est merveilleux, au moins pour certains types de document, en particulier pour les mathématiques, par exemple. Les présentations qu'on peut réaliser, avec prosper ou seminar, ne sont pas aussi funs qu'avec powerpoint, mais le rendu typographique est tellement au dessus que la question ne se pose même pas. Par contre, en ce qui concerne un rendu de type presse (en particulier du multi-colonnes de type canard enchaîné, par exemple), c'est plutôt la cata. Il est presque impossible de faire ce que fait XPress. Je remarque d'ailleurs que le problème intéresse les gourous puisque des interventions dans ces directions sont prévues à EuroTex.

Ce qui m'amuse le plus dans la comparaison avec XML, c'est le ridicule achevée de celle-ci.

D'abord bien sûr en terme de rendu. Celui-ci obtenu par FOP est intéressant mais risible par rapport à celui de TeX. C'est d'ailleurs pourquoi des solutions comme PassiveTeX et autres existent pour faire le rendu de XSL:FO grâce à TeX.

D'autre part, comme l'ont indiqué divers contributeurs, écrire du XML c'est super lourd, même avec une DTD (et le support celle-ci dans l'éditeur). Ecrire des formules en MathML relève de la maladie mentale. Les formules TeX sont relativement lisibles et surtout peuvent être écrites relativement rapidement. Celles de MathML sont grotesque de lourdeurs, on en vient même à se demander si ce n'est pas une blague de mauvais goût. Si on ne souhaite pas apprendre le format des formules TeX, on peut toujours utiliser LyX...

XML apporterait de la sémantique. Quelle vaste de blague ! Même pour une formule de maths, la sémantique peut être délicate. Il n'y a même pas de notation standard pour différencier les vecteurs, des matrices et des scalaires, alors à part en utilisant une DTD (ou un schéma) monstrueux je ne vois pas comment mettre la sémantique dans des formules XML. Quant au contenu du texte lui-même, si on utilise LaTeX, il n'y a pas tant de problèmes que ça. De plus, il faut bien garder à l'esprit que la soi-disant sémantique de XML est obtenue au prix fort, à savoir par l'introduction de centaines de tags, comme dans DocBook, par exemple.

Le plus fun bien sûr c'est que TeX est présenté comme un langage de description de page, alors que c'est en fait un langage tout court. On peut programmer en TeX et comme l'a déjà indiqué quelqu'un, LaTeX est justement un programme TeX (un ensemble de macros). La seule chose comparable en XML est XSL, et franchement, c'est beaucoup moins accessible que TeX. Le gros avantage de TeX c'est qu'on peut faire simplement les choses simples, comme par exemple écrire une macro pour une notation particulière dans un article de math. En XSL, c'est tout simplement l'enfer. Les feuilles de style DocBook par exemple sont tout monstrueuses. Aller ajouter un truc là dedans relève de l'exploit, alors que n'importe qui est capable d'apprendre à utiliser basiquement LaTeX en lui ajoutant quelques macros bien senties. Je ne dis pas que la programmation TeX avancée est facile, c'est tout le contraire. TeX est bourré de hacks débiles tout à fait dans l'esprit de son créateur Knuth (le genre à couper les cheveux en mille), cf http://www.eleves.ens.fr:8080/home/madore/misc/best_of_GroTeXdieck/(...) par exemple. Mais XPath, le composant magique de XSL, est tout aussi bourré de hacks débiles. Je ne dis pas que XSL+XML est inutile, loin s'en faut, mais pour taper un rapport sans un outil totalement wysywig (genre open office pour DocBook) ou qui aide énormément (genre emacs avec la DTD de DocBook), on est bein dans la merde. Et quand on utilise de tels outils, adieu la souplesse. Car pour adapter DocBook à ses propres besoins, il faut un niveau d'expertise énorme. Bref, de fait en XML on n'a pas vraiment de possibilité de programmation, sauf en étant un expert d'un langage étrange et merveilleux (XSL) dont la sémantique est totalement martienne pour un programmeur classique.

Voilà, voilà.

et puis je trouve FOP vraiment _lourd_ ! les tags sont vraiment trop verbeux.

Les tags FOP, c'est-à-dire XSL:FO ne sont pas destinés à être écrits à la main, contrairement à LaTeX. Ils sont effectivement d'une lourdeur monstrueuse, mais on s'en fout, on utiliser une feuille de style, donc en fait on ne voit pas les tags.

Ceci étant, je suis d'accord le rendu de TeX sur certains documents est actuellement imbatable.

Oui, et puis il faut aussi voir les tarifs de Oracle en version répartie (ou de DB2, d'ailleurs).

nous allons l'appeler Plan 9

Plan 9 from outer space, s'il te plait !

D'après ce que j'ai compris, c'est beaucoup plus qu'un broadcast sur les requêtes puisque le moteur intègre une analyse des requêtes pour les distribuer de façon "intelligente". De plus, les auteurs ont fait les benchs classiques (genre le truc de TPC) et ont obtenu un speeup très intéressant (linéaire jusqu'à 8 machines, je crois). Il y a eu une discussion à ce sujet sur theserverside (http://www.theserverside.com/home/thread.jsp?thread_id=19114&ar(...) )

l'article sur les coîts

Du cul dans MISC ?! Trop puissant ! (je sais, ça s'écrit coït).

D'accord sur le diagnostic, mais pas sur la conclusion. La sécurité fait justement partie des problèmes techniques pour lesquels une solution technique seule n'existe pas, un peu comme pour la protection des oeuvres numériques. Il faut bien sûr des mesures techniques, mais il faut aussi beaucoup d'autres choses. Pour continuer l'analogie avec les oeuvres numériques, on peut penser aux CD protégés contre la copie. Ces derniers emmerdent les utilisateurs honnêtes (impossible à lire sur un PC, sur une auto-radio, etc.) et le risque pour les majors est de perdre encore plus de consommateurs. Ceci peut être rapproché du phénomène des anti-virus qui se déclenchent pour un rien et que les utilisateurs désactivent, ou encore des mots de passe qu'on doit changer tous les mois et qui deviennent toto1 en janvier et toto12 en décembre ! Bref, une mesure technique n'est utile que si elle s'accompagne d'une reflexion sur sa mise en oeuvre. Ce que j'aime bien dans misc c'est justement que ce n'est pas un journal d'informatique, mais bien un journal sur la sécurité informatique, donc avec de l'informatique, du droit, des conseils relevant effectivement de la psychologie, etc.

Bon, sinon, tu n'as pas aimé mon article sur la sécurité en Java ;-) ? Parce que ça, c'est quand même de l'informatique, non ?