Java libre : OpenJDK est disponible

Posté par  . Modéré par j.
Étiquettes :
0
9
mai
2007
Java
Sun met à disposition son SDK Java, comme cela avait été promis. Il reste des parties non libres (rendu des polices, partie sonore) parce que l'auteur originel refuse de libérer son code. Sun prévoit de les fournir sous forme de greffon "propriétaire" et tente de développer une alternative libre.

La prochaine étape concerne le maintien de la compatibilité, Sun développe un processus de test d'applications avec cette « nouvelle » version de Java. La personne interrogée par InternetNews - Rich Sands, community marketing manager - espère ne pas voir de forks à foison comme on peut en voir parmi les distributions Linux.

Sun entend également impliquer fortement la communauté dans cet OpenJDK en créant un « Interim Governance Board » avec deux membres de chez Sun et trois autres de l'extérieur. Différents développeurs de chez Sun en parlent sur leurs blogs respectifs et le code source peut être téléchargé sur le site officiel de l'OpenJDK.

NdM : C'est un des piliers de l'informatique moderne qui fait aujourd'hui un grand pas en avant en libérant un bout de logiciel largement déployé, voire quasiment incontournable. C'est aussi la fin d'une polémique.

Aller plus loin

  • # Pourquoi forker?

    Posté par  . Évalué à 10.

    À mon avis, il n'y a principalement que 2 raisons pour forker:
    _ problème de licences: comme ce fut le cas pour le fork Xfree -> X.org
    Mais ici Java étant sous licence GPL, il n'y a aucune raison de forker (pour le moment! Si Sun décidait de revenir sur cette décision, c'est autre chose).
    _ Refus ou réticence en ce qui concerne les patches, améliorations, fonctionnalités venant de développeurs extérieurs: ces derniers décident alors de forker pour pouvoir intégrer leurs bouts de code et ainsi faire évoluer à leur façon le projet. Ce cas s'est rencontré lors du fork Compiz -> Beryl (mais les dév ont finalement trouvé un arrangement, semblerait-il).


    La première raison étant hors course, de par le choix de la licence pour Java fait par Sun, il ne reste que la 2° possibilité!
    Sun ayant décidé de ne placer que 2 gars à eux sur les 5 du « Interim Governance Board » (mais quels sera les pouvoirs et influences de cette Board ?), on peut penser que l'avis de la Communauté sera pris en compte... Et que donc ce 2° cas ne devrait pas se produire!


    du moins, espérons-le! Sun a fait d'énormes efforts pour s'ouvrir, ce n'est pas pour au final laisser les gens "extérieurs" sur le pas de la porte

    • [^] # Re: Pourquoi forker?

      Posté par  (site web personnel) . Évalué à 9.

      En fait, le cas 2 va se produire tout le temps. Java est un vrai terrain de jeu pour la recherche sur les langages de programmation et sa sortie en open source va permettre de faire de nombreuses expérimentations. On peut penser par exemple à des generics à la C# (des vrais, pas avec de l'effacement de type) ou tout un tas d'autres choses (beaucoup moins "basiques) qui nécessitent des modifications non compatibles de la JVM, quelque chose dont Sun ne veut pas entendre parler pour l'instant.

      Bien entendu, ces forks n'auront aucune conséquence sur le projet principal, sauf quand l'un d'entre eux apportera vraiment quelque chose. Il sera alors vraisemblablement intégré dans le projet principal. J'espère que tout ça démontrera à Sun qu'il ne fallait pas avoir peur du grand méchant fork :-)

      • [^] # Re: Pourquoi forker?

        Posté par  (site web personnel) . Évalué à 5.

        Oui le peur de Sun c'est que de nouvelles versions de Java incompatible entre elles apparaissent (comme MS l'avait tenté à l'époque), que du coup on ne soit jamais sûr qu'un programme Java écrit pour telle version fonctionne sur telle autre.

        Dans la pratique ça a peu de chance d'arriver, mais ce n'est pas impossible.

        • [^] # Re: Pourquoi forker?

          Posté par  (site web personnel) . Évalué à 8.

          Le nom Java est protégé par le droit des marques, il est impossible de distribuer un machin s'appelant Java et incompatible, ça limite pas mal les risques.

          • [^] # Re: Pourquoi forker?

            Posté par  (site web personnel) . Évalué à 5.

            Oui bien sûr, le risque vient plus des distributeurs. Imaginons que Redhat crée une version incompatible de Java qu'il appelle Hata et qu'il ne distribue que cette version dans ses distributions, c'est là que ça risque de faire mal.

            Mais bon, je pense sincèrement que le risque est réduit.

            • [^] # Re: Pourquoi forker?

              Posté par  (site web personnel) . Évalué à 7.

              Si je vois pour ma boite et mes clients (nous sommes spécialisés Java), la première distrib qui fournit un JDK non compatible sera automatiquement exclue de toute install client ou serveur, donc à mon avis, le risque est vraiment très très faible.

              Pour schématiser, on se fout un peu de la JVM justement parce qu'elle est censée respectée la norme. La première qui fout le bordel ne sera plus utilisée :)
              (je schématise, les perfs varient suivant les JVMS).

              http://about.me/straumat

              • [^] # Re: Pourquoi forker?

                Posté par  . Évalué à 9.

                c'est vrai quand tu es dans un systeme de concurrence normal.
                Ca l'est beaucoup moins quand tu es dans un systeme d'abus de position dominante.
                suivez mon regard

            • [^] # Re: Pourquoi forker?

              Posté par  . Évalué à 4.

              Surtout que la license choisie par Sun est la GPL. Donc meme si RedHat cree une version Hata, les sources devront en etre disponibles.

  • # Et la JVM ?

    Posté par  . Évalué à 10.

    Je n'ai pas suivi de près l'évolution de la situation, d'autant que n'étant pas informaticien je n'en comprends qu'une partie.

    A t'on une idée de quand la JVM libre sera disponible. J'entends par là, ce que le commun des mortels installe pour pouvoir exploiter des applis Java sur se machine (ou par exemple déclarer ses revenus sur les sites impots.gouv.fr) ?

    J'ai une machine PPC, donc pas de JVM Sun disponible. J'attends beaucoup de la libération qui permettrait sans doute d'avoir enfin une version "Sun", "à jour", sur ma machine.

    Alors Mme Irma est-elle dans la salle ? :-)

    • [^] # Re: Et la JVM ?

      Posté par  . Évalué à 5.

      > Alors Mme Irma est-elle dans la salle ? :-)

      Elle n'a qu'une boule de crystal et pas de PC.

      > A t'on une idée de quand la JVM libre sera disponible.

      6 ou 9 mois. C'est prévu pour Fedora 8.

      • [^] # Re: Et la JVM ?

        Posté par  . Évalué à 1.

        Merci beaucoup pour cette info, ça donne une indication.

  • # Bravo

    Posté par  (site web personnel) . Évalué à 7.

    Félicitations à tous ceux qui ont pu faire en sorte que cela arrive. C'est réellement une bonne nouvelle !

    Je suis un peu surpris par:
    Il reste des parties non libres (rendu des polices, partie sonore) parce que l'auteur originel refuse de libérer son code

    Je pensais que l'intégralité du JDK avait été développée par Sun, et que le code écrit par ses employés auraient été soumis à un copyright Sun et non personnel. Quelqu'un aurait plus d'informations à ce sujet ?

    • [^] # Re: Bravo

      Posté par  (site web personnel) . Évalué à 5.

      Beaucoup d'entreprises achètent des petits bouts de code existant pour des parties de leurs produits, et là bien sûr l'auteur initial garde son copyright.

      C'était par exemple le problème de BeOS, vu le nombre de morceaux n'appartenant pas à Be Inc dans le code, cela limitait l'intérêt de la libération du code.

      • [^] # Re: Bravo

        Posté par  . Évalué à 3.

        merci Sun ! =)

      • [^] # Re: Bravo

        Posté par  . Évalué à 2.

        >C'était par exemple le problème de BeOS, vu le nombre de morceaux n'appartenant pas à Be Inc dans le code, cela limitait l'intérêt de la libération du code.

        Bof, j'ai un doute que ce ne soit pas plutôt l'attrait des 50 Millions de dollars qu'a récupéré BeInc quand ils ont vendu leur code et propriété intellectuelle a Palm.

        A mon avis, les développeurs d'Haiku n'auraient pas craché sur le code de BeOS (même incomplet) quand ils ont commencé a développer leur clone..

    • [^] # Re: Bravo

      Posté par  . Évalué à 6.

      Ben tout ce qui est rendu des polices et Java2d ça vient de chez kodak par exemple. Et kodak refuse de mettre ça en GPL. Donc les mecs de Sun disent : "on fournit ça dans un blob binaire, et on espère que y'aura assez de motivés pour coder ça en GPL sans perte de fonctionnalités ni de performances" (ce qui sera dur pour Java2d)

      • [^] # Re: Bravo

        Posté par  (site web personnel) . Évalué à 10.

        je n'ai jamais touché aux polices sous java. Mais j'ai travaillé quelques temps sur un soft qui lui devait gérer les polices (une sorte de moteur de rendu de texte "vectoriel" - car c'est pas exactement ça - avec des transformations, rotations et tout le bordèl qui va avec)
        Et y'a pas à dire, une bonne gestion de polices c'est très très compliqué.
        Entre les différents formats, les polices parfois incorrectes et pas mal de problèmes liés aux calculs des emplacements de lettres, c'est vraiment bordélique (il suffit de regarder comment est fait freetype pour avoir une idée)
        Si on rajoute les problèmes d'interligne, de lettrines, ...
        d'ailleurs il est assez intéressant de tapper un même texte, même paramétrage, même police, même taille, ... sur plusieurs logiciels (prendre quark et indesign pour ceux qui ont, et rajouter scribus) et de regarder les différences. C'est parfois énorme !

        D'ailleurs, pour ceux qui ont un vieux firefox par exemple (avant cairo je dirais, mais sans grande conviction), très souvent en sélectionnant une portion d'une ligne de texte contenant plus d'un style on arrive à faire bouger les lettres (quelques unes vont se décaler d'un px par exemple, c'est peu mais ça se voit). Tout ça à cause de la manière dont était calculés les emplacements des lettres.

        M'enfin, tout ça pour souhaiter un bon courage aux développeurs qui vont s'en charger (c'est galère mais tout de même intéressant, sans compter les gruges pour les écrans tft, et tout plein d'autres bonnes choses ;-) )

        • [^] # Re: Bravo

          Posté par  (site web personnel) . Évalué à 10.

          Cela prouve l'immensité de l'oeuvre de Knuth qui a réalisé TeX et Metafont, un système où le rendu est impeccable, multi-plateforme et d'une stabilité peu souvent reproduite.

        • [^] # Re: Bravo

          Posté par  . Évalué à 9.

          Bof j'ai un firefox 2 et quand je sélectionne des lettres de ton message ça bouge d'un pixel... Mais bon si Firefox faisait autre chose que s'allourdir de version en version tout en privilégiant Windows ça se saurait (oui je sais on est jeudi)

          • [^] # Re: Bravo

            Posté par  (site web personnel) . Évalué à 10.

            je dit pas non sur l'allourdissement, mais sais-tu comment est compilé ton firefox ?
            En gros, qu'utilise-t-il pour se dessiner, est-ce cairo ?
            Car si oui, c'est étrange que ça bouge.
            J'ai pour le moment un 2.0.0.1 packagé par Mandriva et aucun problème

            Le décalage est vraiment typique d'un mauvais arrondi du à la présence de plusieurs runs distincts sur une ligne.
            Je disais plus haut qu'il fallait que la ligne comporte plusieurs styles, mais en fait c'est faut. La sélection en elle-même vient fausser les calculs (quand c'est mal fait) car lors d'une sélection simple, au milieu de la ligne (c'est plus facile pour comprendre) la ligne est découpée en 3 runs :
            * texte non sélectionné
            * texte sélectionné
            * texte non sélectionné

            Et comme les runs sont en partie indépendants, il suffit d'un mauvais arrondi sur le run sélectionné (alors qu'il n'y avait qu'un run avant) pour que toute la suite soit décalé.

            Mais on verra ensuite que ce décalage peut très bien se résorber avant la fin de la ligne simplement par un autre arrondi dans l'autre sens... c'est pour ça qu'on a souvent qu'une partie de texte qui bouge.

            Sinon, un autre test sympa :
            ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

            Si certains aperçoivent des espaces légèrement différents, irréguliers dans cette série de f alors il y a encore des amélioration possible sur leur système de rendu de texte (c'est également l'exemple qui était pris dans les screenshots de la sortie de la version java de QT - voir le journal privé en parlant)

            Evidemment, on peut penser que de si petits écarts sont négligeable, mais c'est très loin d'être le cas, car ceux-ci (il suffit d'en avoir plusieurs par ligne) peuvent foirer complètement la mise en page d'un texte. Imaginons que ces petits écarts empêchent une lettre de rentrer dans la ligne prévue (alors qu'un bon système n'aurait pas eu cette erreur). Dans ce cas, la césure change, ou au pire le mot passe à la ligne suivante. Si ce décalage était au début du texte, on peut aisément visualiser la chaîne de modification apportée à l'ensemble du texte suivant.
            Et pour ceux qui travaillent dans la presse notament, le fait d'avoir un nombre de ligne d'un même article changeant simplement à cause de deux moteurs de rendu différents est difficilement acceptable...

            • [^] # Re: Bravo

              Posté par  . Évalué à 2.

              Après vérification, le décalage n'a lieu que lorsqu'on sélectionne une partie d'une ligne sur un paragraphe qui en fait plusieurs

        • [^] # Re: Bravo

          Posté par  (site web personnel) . Évalué à 3.


          D'ailleurs, pour ceux qui ont un vieux firefox par exemple (avant cairo je dirais, mais sans grande conviction), très souvent en sélectionnant une portion d'une ligne de texte contenant plus d'un style on arrive à faire bouger les lettres (quelques unes vont se décaler d'un px par exemple, c'est peu mais ça se voit). Tout ça à cause de la manière dont était calculés les emplacements des lettres.


          Ah oui le fameux bug, rien à voir avec cairo ni spécifique aux fontes, c'était un problème de prise en compte de la résolution du serveur graphique (dpi) si tu utilisait une résolution différente des deux
          standard (75 et 100) le moteur de rendu perdait les pédales
          effectivement.

  • # D'autres détails

    Posté par  . Évalué à 6.

    Description de la session d'ouverture de la conférence JavaOne sur The Server Side : http://www.theserverside.com/news/thread.tss?thread_id=45311

    Les commentaires de Rich Sands sur OpenJDK : http://java.sun.com/javaone/sf/2007/articles/openjdk_sands.j(...)

    C'est vraiment une nouvelle attendue par beaucoup, et qui va certainement amener des changements sur le déploiement des logiciels Java.
    Il est prévu aussi que cela améliore les tests et la certification de compatibilité (respect des specifications Java), cf la liste des implémentations sur http://java.sun.com/javaee/overview/compatibility.jsp

    • [^] # Re: D'autres détails

      Posté par  (site web personnel) . Évalué à 5.

      Je ne comprends pas que SAP NetWeaver puisse être certifié J2EE 5 ...
      A moins que quelquechose m'échappe, la dernière version de SAP NetWeaver que j'ai utilisée ne suit absolument pas les spécifications JSP/Servlet. On va dire qu'ils s'en inspirent vaguement mais l'implémentation est très libre (par example dans une taglib, PageContext.getResponse() retourne null au lieu de l'HttpResponse ...)

      • [^] # Re: D'autres détails

        Posté par  . Évalué à 4.

        Ce n'est pas le WAS de SAP Netweaver 2004s qui est certifié JEE5 (was 7), c'est le WAS 8 qui n'est pas encore disponible sur les solutions SAP Business Suite ou NW.

        De plus à par les modules internet sales de CRM y a pas grand interet a utiliser des JSP/Servlet sur les WAS SAP.

  • # Standarddefait2standard

    Posté par  (site web personnel) . Évalué à 6.

    C'est une bonne chose que Sun passe Java en GPL, cela va pouvoir permettre à tous d'avoir une JVM et plus si affinité. Si adobe pouvais faire de même avec flash, sa serait bien.

    • [^] # Re: Standarddefait2standard

      Posté par  . Évalué à -4.

      A cette heure, ce n'est que le JDK qui est libéré, c'est à dire que le compilateur (code source --> bytecode java) est sous GPL. Mais la JVM, qui execute le bytecode, et qui est écrit en C (probablement...) n'est pas libre pour le moment.
      C'est certain qu'un compilo libre améliorera les implémentations libres existantes de la JVM.

  • # disponibilité dans les distro

    Posté par  . Évalué à 3.

    Il reste des parties non libres (rendu des polices, partie sonore) parce que l'auteur originel refuse de libérer son code. Sun prévoit de les fournir sous forme de greffon "propriétaire" et tente de développer une alternative libre.
    Ca veut dire que les distro ne vont pas encore pouvoir l'intégrer ?
    Ou alors ca reste utilisable (voir en le mixant avec d'autre projet java opensource) et ca va etre intégré prochainement ?

    • [^] # Re: disponibilité dans les distro

      Posté par  . Évalué à 5.

      Les distributions peuvent déjà intégrer Java hein. (cf debian ou ubuntu)
      Par contre c'est pas en licence libre.
      Pour ce qui est propriétaire, faut trouver des remplaçants (et ça va être dur)

    • [^] # Re: disponibilité dans les distro

      Posté par  (site web personnel) . Évalué à 6.

      Pour le rendu des polices, il me semble que GNU Classpath s'en sort admirablement bien
      http://developer.classpath.org/screenshots/

      et GNU Classpath implémente aussi à 100% javax.sound

      Entre Kaffe, GCJ, Classpath, Harmony OpenJDK a de la concurrence... De quoi prendre la meilleure implémentation de chaque classe pour gagner en performance...

      • [^] # Re: disponibilité dans les distro

        Posté par  (site web personnel) . Évalué à 4.

        Justement, est-il possible de fusionner une partie de ses codes ou, la quantité et la manière de coder est tellement diiférente que la tâche semble impossible ?

        Si la réponse est non, quel est l'avenir des projets comme Classpath ?

        • [^] # Re: disponibilité dans les distro

          Posté par  . Évalué à 3.

          A t'on une chance de voir les différents projets qui visaient à faire une implémentation libre de Java se regrouper et travailler ensemble ???

      • [^] # Re: disponibilité dans les distro

        Posté par  . Évalué à 2.

        Euh...
        Soit les gars de Classpath sont vraiment super super forts, et le Swing de Sun a du souci a se faire.
        Soit ils utilisent une librairie genre GTK2 pour gerer le layout graphique.

  • # plugin Firefox

    Posté par  . Évalué à 8.

    est-ce que cela veut également dire que l'on va pouvoir compiler un plugin java pour Firefox x86_64 ?? j'ai cherché un peu dans les sources, mais je ne vois pas comment faire...

  • # Tres tres bonne nouvelle :)

    Posté par  . Évalué à 10.

    On peut maintenant être fier à 100% de faire du libre en Java, avec des technos comme Eclipse (IDE + RCP), JBoss, Apache, OW2, Glassfish, etc. et maintenant le OpenJDK.

    JG

    • [^] # Re: Tres tres bonne nouvelle :)

      Posté par  . Évalué à 2.

      Yeessss!
      Maintenant, je me pose une question: pour une appli graphique, que vaut-il mieux faire, utiliser swing et être portable ou les bindings de gnome pour une meilleure intégration ?

      • [^] # Re: Tres tres bonne nouvelle :)

        Posté par  . Évalué à -1.

        Concevoir son application de façon a pouvoir en développer plusieurs sans qu'il y ait besoin de modifier le code.

        Dans l'idéal un système client/serveur pour pouvoir changer d'interface à la volée. Comme pour les outils de P2P : un démon amuled et des interfaces amulegui/amuleweb/...

        Autrement, un bon design objet devrais faire l'affaire.

      • [^] # Re: Tres tres bonne nouvelle :)

        Posté par  . Évalué à 10.

        Tu peux essayer QT Jambi, qui est libre, marche sur toutes les plateformes, développé par une entreprise qui encourage le libre !

      • [^] # Re: Tres tres bonne nouvelle :)

        Posté par  . Évalué à 1.

        Moi je dirais SWT et JFace. ca me semble le meilleur compromis entre vitesse d'execution et look natif pour les plateformes. Par contre il faut une lib différente pour chaque plateforme.

        • [^] # Re: Tres tres bonne nouvelle :)

          Posté par  (site web personnel) . Évalué à 4.

          Swing est tres "design pattern". Il offre tout un tas de solutions élégantes. Par exemple l'impression avec l'api document, la création de masques de saisie, la gestion des évenements (les fameux listeners), le placement dynamique des composants, la création de nouveau composants ...
          Attention je ne dit pas que les autres ne savent pas le faire, mais personnellement, j'adore. Je comprends bien comment ça tourne, et ça me permet de faire des choses correctes sans être un fou du design d'interfaces.

          Par contre, je trouve qu'il manque cruellement quelque chose au dessus de swing. Un toolkit plus simple, plus "evenementiel". Un truc pour faire des interfaces en quatre clics. Parce que si swing sert à faire des interfaces graphiques, ça reste une implémantation du pattern MVC. Alors oui, faire un masque de saisie en allant modifier le modèle. C'est propre, c'est élégant, c'est tout ce qu'on veut mais c'est chiant.

          Au niveau de la lourdeur sous linux, j'ai quand même l'impresion que c'est la liaison entre la couche basse (awt) et swing qui coince.
          _ Lenteur pour redessiner les composants
          _ Récuperation des évenements aléatoire
          ...
          A mon avis rien de rédibitoire maintenant que les génis du libre vont s'y coller.

          Apres j'espere que cela va faire décoller certaines technologies telles que java webstart. Parce que bon, pour des applications riches, portables, déployés par le web et connectées (ce qui semble devenir la normme ) java est quand même un incontournable.

  • # Merci et plus

    Posté par  (site web personnel) . Évalué à 9.

    Tout d'abord je vous invite à faire un tour sur http://planet.classpath.org/ pour lire les réactions entousiastes des devs de classpath

    Ensuite merci Sun.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.