• [^] # Re: Sympa ce comparatif

    Posté par . En réponse à la dépêche "The Great Computer Language Shootout" Divers langages et compilateur au banc d'essai. Évalué à 3.

    Exact, l'article parle de bug de JVM, mais en plus il y a des bugs de la librairie standard.

    Trouve moi une librairie / machine virtuelle avec un minimum de code sans aucuns bug et fais moi signe ...

    En plus Sun met un temps dingue pour les corriger ses bugs: il faut compter 2-3 ans pour des bugs pour lesquels des milliers de personnes ont vote dans la BugParade..

    C'est clair que certains bugs trainent depuis longtemps mais on ne peut pas dire que Sun ne corrige pas les bugs, il y en a énormément de corrigés très régulièrement ...

    Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.

    Je dois avouer que je suis plutôt côté serveur, donc tu as sans doute raison, dans ces domaines peut être que les librairies standards montrent leurs limites ... Mais il y a peut-être d'autres librairies qui te permettent de faire ce genre de chose ?

    Mouais c'est une drole de feature quand meme!

    Ils ne disent pas que c'est une feature non plus, c'est juste un comportement induit par le modèle de mémoire de Java, et encore le problème ne survient que lorsque le code s'exécute sur des machines multiprocesseurs. Si ils avaient choisi un autre modèle de mémoire, peut-être un autre problème aurait surgit autrepart, tout modèle a ses avantages et ses inconvénients ...

    Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
    Le deboguage d'application multi-threadee avec des comportements aussi bizarre des JVM doit etre coton..


    La programmation multithreads n'est jamais trivial et demande une très bonne connaissance des comportements de la machine (virtuelle ou non) sur laquelle on développe ... C'est un des domaines les plus complèxes du génie logiciel ...