: OpenJDK 6 passe le TCK

Posté par GeneralZod (). Modéré le 20 juin 2008.
0
La dernière version d'OpenJDK 6 passe le rigoureux Java Test Compatibility Kit (80 000 tests, 1 million de lignes de code). En clair, OpenJDK est une implémentation conforme aux spécifications Java 6 de Sun.

Aujourd'hui Fedora 9 est la première distribution GNU/Linux à inclure un JDK libre 100% conforme aux spécifications Java 6 grâce aux efforts des ingénieurs de Sun, RedHat et de la communauté Fedora. RedHat envisage d'inclure OpenJDK dans la prochaine RHEL 5.3. Le « Java trap » (piège java) est définitivement mort.

Un récapitulatif des épisodes précédents est disponible dans le suite de l'article.

> Lire la suite (77 commentaires, moyenne: 3,1).   [dépêche : 2414 caractères]

Vous avez demandé le commentaire #942857.

[+] Bof

Posté par GPL (Jabber id, ) le 20/06/2008 à 14:29. (lien). Évalué à -10.

Est-ce les composants de crypto sont toujours fermés?

Est-ce qu'on peut le compiler *sans* une version fermée de java (aka juste avec un compilateur C++)?

Est-ce que je peux télédéclarer mes revenus avec ce JDK sans me faire envoyer bouler par le site de la DGI (Direction Générale des Impôts)? (Sachant qu'un canal SSL est largement suffisant).

Est-ce que si je suis contributeur de code à ce bloat, je suis obligé d'abandonner mes droits au conseil d'administration de Sun?

Qui sont les fous qui vont maintenir la pile logicielle suivante pour une application java:
1 - Noyau (Ouch!)
2 - Le compilateur C (la tool chain en fait)
3 - La bibliothèque C standard
4 - Le compilateur C++ (un truc de barge)
5 - La bibliothèque C++ standard (un truc de fou furieux).
6 - Les 80Mo de code compressés du JDK en C++ brain damage (no comment...)

Pour ma part, je m'arrête au niveau 3.5 (en effet je triche, j'utilise des bibliothèques C en plus de la bibliothèque C standard).

Dsl mais je ne suis pas fan de bloatware. Surtout que celui-là, sans Sun, déraisonable de le maintenir... donc dire que la java trap est morte... mouaif, elle se cache sous une couche "open source" mais elle est toujours là. Y a même MS/Novell qui fait la même chose avec son mono (.net).
Java n'est qu'un nouveau COBOL (hum... il est poilu celui-là!)

Un point positif, il y a quand même JNI pour l'intéropérabilité: je peux appeler du code JAVA dans mon code C et vis-et-versa (en théorie).

  • [^]Re: Bof

    Posté par GeneralZod () le 20/06/2008 à 14:49. (lien). Évalué à 9.

    > Est-ce les composants de crypto sont toujours fermés?
    Non, depuis un bon moment déjà.
    http://mail.openjdk.java.net/pipermail/security-dev/2007-Sep(...)

    > Est-ce qu'on peut le compiler *sans* une version fermée de java (aka juste avec un compilateur C++)?

    Oui, GCC/GCJ suffit à compiler OpenJDK, d'ailleurs, OpenJDK 6/IcedTea n'aurait jamais pu être distribué dans Fedora si ce n'était pas le cas.

    > Est-ce que je peux télédéclarer mes revenus avec ce JDK sans me faire envoyer bouler par le site de la DGI (Direction Générale des Impôts)? (Sachant qu'un canal SSL est largement suffisant).

    Il ne manque plus qu'un plugin web fonctionnel à 100% au lieu de 95%
    Le TCK garantit quant à lui que le JDK/JRE est 100% conforme aux spécifications de Sun donc à ce niveau-là aucun souci.

    > mouaif, elle se cache sous une couche "open source" mais elle est toujours là.
    La java trap concernait l'environnement d'éxécution non libre, aujourd'hui ce n'est plus le cas.
    Au passage, OpenJDK deviendra l'implémentation de référence dès Java 7 et remplacera définitivement l'implémentation propriétaire de Sun, c'est objectif de la release.

    > Qui sont les fous qui vont maintenir la pile logicielle suivante pour une application java:
    C'est le cas de la totalité des langages de haut niveau.
    Je suis ingénieur en système embarqué et j'apprécie au moins tout autant que toi le C, mais il faut reconnaitre que Java et autres langages de haut niveau ont leur utilité.
    De plus, la communauté libriste est largement capable de maintenir une pile logicielle comme Java, ce n'est pas les développeurs de Python, Mono, Perl, Ruby qui me contrediront.

    [^]Re: Bof

    Posté par Barret Michel (page perso, ) le 20/06/2008 à 15:01. (lien). Évalué à 4.

    Quel est le rapport avec la STL ? et gcc ?

    Les dev de la STL, de gcc, de g++ et de linux reste à leur tâche si c'est ce qu'il préfèrent. Il existe depuis déjà quelques temps des implémentations libres du JDK mais pas parfaite. Ces dev vont probablement passer à OpenJDK.

    --
    Debian Sid

    [^]Re: Bof

    Posté par Larry Cow () le 20/06/2008 à 15:29. (lien). Évalué à 4.

    Sachant qu'un canal SSL est largement suffisant

    Que veux-tu dire? Que la DGI aurait pu se passer d'une applet et utiliser les fonctionnalités standards de SSL?

    Il me semblait qu'on avait déjà largement débattu de ce point-là...

    [^]Re: Bof

    Posté par cykl (Jabber id, ) le 20/06/2008 à 16:48. (lien). Évalué à 6.

    En pendant que tu réinventes les listes chaînées ou un mécanisme de d'introspection moi je suis en train en boire des margarita sur la plage.

    Quand tu utilises de la bonne facon les bonne technos, le coût runtime est infime par rapport au gain de robustesse et de productivité. Par contre aucun langage n'empêche les mauvais codeurs/architectes de pondre des bouzes. D'ailleurs tu peux me donner des pointeurs sur tes contributions d'exceptions au logiciel libre ?

    Exercice supplémentaire: Regarder comment fonctionnent les JVM. Comparer l'assembleur produit par gcc et hotspot.

    • [^]Re: Bof

      Posté par zul (Jabber id, page perso, ) le 20/06/2008 à 17:13. (lien). Évalué à 0.

      Quand on parle de bonne techno, dans le même thread que java, ça a tendance à me faire sourire. (facile on est vendredi).

      Quelles sont les qualités de java, à par d'être un langage vu par tous à l'école, et une techno de décideurs pressés ? (et aussi générer un maximum d'architectures bloatwares (le problème ne vient pas uniquement du langage, mais de la façon de penser complétement biaisée des architectes logiciels en bonne partie amha), chiantes à maintenir, donc qui rapporte de l'argent).

      Qu'est qui fait que java est robuste ? J'ai jamais rien vu d'impressionant, à par catcher le milliard d'exception qui peut etre levé par le système.

      Pourquoi quand on parle de bonnes technologies ne parle-t-on pas plutot des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).

      • [^]Re: Bof

        Posté par cykl (Jabber id, ) le 20/06/2008 à 17:54. (lien). Évalué à 10.

        > Quand on parle de bonne techno, dans le même thread que java, ça a tendance à me faire sourire. (facile on est vendredi).

        Tu remplaces Java par J2EE et je suis d'accord avec toi :-) Souvent quand on parle de Java le gens pensent J2EE ou Java 1.2. Depuis ca a un peu évolué dans le bon sens tant en perf qu'en fonctionalités.

        > Quelles sont les qualités de java

        Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée. En général tu fais facilement ce que tu veux. Tu passes plus de temps à faire des choses fun que réinventer la roue en général.

        Ce n'est pas LA solution, et je n'irais pas l'utiliser pour n'importe quoi.

        > Qu'est qui fait que java est robuste ?

        Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.

        > des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).

        Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés). Si tu veux être viable à long terme il faut pouvoir attirer des gens et autant que possible faire le moins de travail toi même.

        Attention je n'ai jamais dit que Java c'était LE truc génial et inégalé. C'est un outil adapté à certains problèmes qui a l'avantage d'être mainstream (et avec OpenJDK on peut espérer voir des gens du LL débarquer).

        Même si tu ne veux pas faire de Java, réjouis toi de l'ouverture de Hotspot. Ca doit juste être un des bouts de code les mieux optimisés au monde. Il y a aussi pas mal de projet réutiliser la JVM, et ses perfs, pour d'autre langage (ca fait un .Net portable).

        Après si quelqu'un veut discuter technique je pense avoir le background C et Java pour apporter quelques réponses sur les perfs etc.

        • [^]Re: Bof

          Posté par zul (Jabber id, page perso, ) le 20/06/2008 à 18:29. (lien). Évalué à 1.

          > Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée.

          Facile et difficile à utiliser sont des notions je pense complétement lié à l'éducation. Si on apprenait aux gens à réfléchir autrement, en particulier, si ils avaient des cours un peu poussé de programmation fonctionnelle, ça changerait surement la donne. Ce n'est pas un avantage du langage en soit, juste la conséquence d'un manque de culture informatique, dans le but d'être "attractif pour l'entreprise".

          Quand à la portabilité, j'attend de pouvoir compiler facilement en natif openjdk sur un BSD ou une architecture exotique, on verra ensuite. :)

          > Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.

          Evidemment, comparé java et C, java s'en tire sur la robustesse. Je parlais évidemment en comparaison avec les langages sous-cités. Quand au projet à 1M de ldc, il serait intéressant à ramener aux nombres de concepts manipulés. Je trouve java très inefficace de ce point de vue (écrire beaucoup de code pour exprimer peu de chose, même avec sa superbe librairie standard complexe).

          > Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés).

          Pour la partie difficiles, se rapporter au layus sur la facilité du java. L'ecosystème est faible, parce que le système se mord la queue (il faut la confiance dans une grosse boite qui l'utilise ou qui le developpe ...). À noter qu'il me semble que cet argument est moins vrai pour erlang vu qu'ericson l'a pas mal poussé et qu'il a de nombreuses caractéristiques intéressantes.

          Pour les performances, je n'ai pas remis en doute les performances de java, juste des architectures :) On peut avoir la vm la plus optimisé du monde, une mauvaise architecture et des mauvais algos (si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java), ça ne changera rien au résultat. Et ça aucun langage n'y peut rien. Seule l'éducations et une bonne formalisation peuvent faire des choses à ce sujet ...

          • [^]Re: Bof

            Posté par cykl (Jabber id, ) le 20/06/2008 à 19:21. (lien). Évalué à 7.

            Je suis complètement d'accord sur la notion de facilité et du cercle vicieux.
            Je prends une vision pragmatique de développeur/chef de projet. Tu as un choix a faire maintenant tu fais quoi ? (il n'y a pas de réponse unique)

            Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.

            D'un point de vue encore plus personnel, je me fou de la soit disant "beauté" du langage. Si j'écris 5 lignes de code au lieu de 10 je suis content. Mais ce qui m'importe le plus c'est de pouvoir faire les choses (outils, libs etc.), comprendre aisément du code de quelqu'un d'autre, avoir une base de code maintenable sur la durée, quand je code un lib avoir des utilisateurs potentiels et ne pas sortir mon soft 3 ans après avoir épuisé les crédits.

            Et par pitié n'assimile pas une techno a quelques uns de ses utilisateurs: "si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java". Y'a un marché de dev Java important. Ca draine les déchets, c'est évident. Mais je pense pas régresser mentalement lorsque je passe du C au Java. Tout comme il serait bon de ne pas traiter d'imbéciles les mecs d'Apache, de Sun ou qui font des archis comme Yahoo, Ebay ou LinkedIn.
            Dans l'informatique pro y'a 70% de boulets, faut bien qu'ils utilisent quelque chose. Tu n'y changeras rien (et ils ont une petite chance de faire moins de mal en Java qu'en C ou C++ :-) )

            • [^]Re: Bof

              Posté par patrick_g (page perso, ) le 20/06/2008 à 20:27. (lien). Évalué à 3.

              >>> Dans l'informatique pro y'a 70% de boulets

              Je te trouve optimiste. La loi de Sturgeon stipule pourtant que "90% de n'importe quoi ne vaut rien".

              http://en.wikipedia.org/wiki/Sturgeon's_law

              [+] [^]Re: Bof

              Posté par zul (Jabber id, page perso, ) le 21/06/2008 à 02:54. (lien). Évalué à -2.

              > Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.

              Je ne vois pas bien ce que ça démontre. A par 1/ bloatware (qui a besoin d'un "framework" pour coder un pauvre bot IRC 2/ la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu). En utilisant java, tu as à mon avis, augmenter considérablement la taille de ton projet (en ligne de code), et perdu sur l'aspect dynamique de la chose. Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500, c'est ton choix. Mais je vois pas la portée de l'argument. Mais hésite pas à argumenter plus avant.

              Pour en revenir sur le chef de projet, utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats. Sauf si tu veux te taper dans les 90% (ce qui me semble un chiffre plus raisonnable) des gens peu compétents. Evidemment, ils risque d'être plus cher, mais on peut pas avoir l'argent du beurre, et le cul de cremière :).

              Je ne pense pas avoir parlé de la "beauté" du code. J'ai parlé de l'expressivité du langage et des choses assurés par le compilateur. Y'a des choses assez inexprimables sans evaluation paresseuse par exemple. L'inférence de type c'est un truc à mon avis bien plus puissant que les trucs utilisés pour faire de la généricité en java ou en C++... Et je n'ai jamais parlé de C. Le C est utile pour un certain nombre de choses, en particulier le système. J'ai toujours parlé de langages de haut-niveau.

              Et même pour les "boulets", le java est encore largement trop permissif. Un langage encore plus contraint sera à mon avis bien plus efficace, en supprimant encore de nouvelles erreurs.

              • [^]Re: Bof

                Posté par cykl (Jabber id, ) le 21/06/2008 à 12:58. (lien). Évalué à 3.

                > 1/ bloatware (qui a besoin d'un "framework" pour coder un pauvre bot IRC

                framework = bibliothèque :-)

                https://rome.dev.java.net/
                https://pircbot.dev.java.net/
                http://code.google.com/apis/youtube/overview.html
                http://mina.apache.org/

                Mina est 100x overkill mais j'avais envie de jouer avec. Si utiliser des libs c'est du bloat...

                > la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu).

                C'est con c'était le but et j'ai tout de même écrit une version python.

                > Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500

                Ca fait 500 lignes de code pour prendre ses entrées sur X chan IRC, telnet et parser régulièrement l'output XML du serveur d'intégration continue; dispatcher ces infos sur différents planet en fonction de la config chaque planet poussant les infos sur des flux RSS ou sur IRC.

                > Mais je vois pas la portée de l'argument

                Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.

                > utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats

                Non. Ca te fais prendre des universitaires qui n'y connaissent pas forcément grand chose en ingénierie logiciel :-)

                • [^]Re: Bof

                  Posté par zul (Jabber id, page perso, ) le 21/06/2008 à 13:58. (lien). Évalué à 1.

                  > framework = bibliothèque :-)

                  Tu as une définition assez personnelle de la notion de framework. Ma définition s'approche plus de celle de wikipedia (et je suppose que c'est "un point de vue majoritaire".

                  Evidemment, utiliser des libs, ce n'est pas forcément bloatware, (quoi que ça dépend des libs). C'est un exemple parfait pour démontrer qu'il s'agit surtout d'un collage bout à bout de libs, sans trop se poser de questions, sans problème d'algorithmie, etc ...

                  > Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.

                  Ton argument, c'est que pour qu'un langage soit un bon choix, il faut que ce soit un bon choix dès le départ, cad qu'un gros industriel le sorte avec assez de vie pour qu'ils soient utilisables. Ici encore, le système se mord la queue. Plus un système utilisé, et plus le nombre de bibliothéques augmentent, dans un grand cercle virtueux. Et inversement, aucun 'petit langage' ne peut vraiment émerger.

                  Pour finir, je citerai alors scala, qui profite de l'ensemble des bibliothèques java, mais qui apporte quelques améliorations sustanciels des langages préalablement suscité.

                  Et sinon, bravo pour les moinssages à l'emporte pièce, l'auto-modération est vraiment quelquechose qui m'est vraiment de plus en plus insupportable, surtout lorsqu'elle est faite sur des posts plus ou moins argumentés, sans grossiéretés, ni propos choquant (à part de défier la PENSÉE UNIQUE) (respect à tous ... :)

                  [^]Re: Bof

                  Posté par Sytoka Modon (page perso, ) le 21/06/2008 à 23:47. (lien). Évalué à 2.

                  As tu regarder du coté de Perl ? Faisant pas mal de Perl, je ne suis pas objectif mais il me semble que la bibliothèque Perl, via le CPAN est immense et que dans le nom même de Perl, il y a déjà ta problèmatique de bot IRC de traiter. Bref, Perl me semble parfaitement adapté à ton exemple. J'irais par exemple voir comme cela du coté de POE.

                  • [^]Re: Bof

                    Posté par cykl (Jabber id, ) le 22/06/2008 à 13:23. (lien). Évalué à 2.

                    Je faisais des golfs il y a 8 ans :-)

                    J'ai choisi cet exemple au hasard pour montrer que l'écosystème d'un langage est aussi très important. Clairement Perl n'a rien à prouver de ce point de vue là.