OpenOffice.org version 2.0 et Java

Posté par (page perso) . Modéré par Amaury.
Tags : aucun
0
29
mar.
2005
Bureautique
La colère monte chez de nombreux développeurs et utilisateurs des logiciels libres à propos de la nouvelle version d'openOffice.org. En effet celle-ci repose plus fortement qu'avant sur la technologie Java ce qui pose de nombreux problèmes juridiques et techniques et qui pourrait favoriser un développement plus rapide des alternatives.

Un article du site Newsforge fait le point sur la controverse. La version stable actuelle d'Openoffice.org (version 1.1.4) utilise déjà Java et elle requiert un JRE (Java Runtime Environment) pour pouvoir profiter de toutes ses fonctions. Néanmoins ce ne sont que des fonctionnalités annexes et quelque peu périphériques qui dépendent de Java (le driver JDBC pour les bases de données Java ; les filtres XSLT, etc.) à l'exception notable des outils d'accessibilité qui peuvent êtres cruciaux pour certaines personnes handicapées.

Le problème posé est qu'il n'existe pas de version libre de Java ou pire encore, qu'il n'existe même pas de version officielle propriétaire de Java pour certains systèmes d'exploitations (FreeBSD par exemple) ou certaines architectures (PowerPC par exemple).

En dépit de cette difficulté cette dépendance Java n'avait pas posé jusqu'à présent de problème particulier au monde du logiciel libre. Certaines distributions ont choisi de désactiver le support Java d'OO.o et de se passer des fonctions annexes. D'autres proposent au contraire un support complet pour leurs versions non-libres sur certaines architectures.

La version 2.0 d'OpenOffice.org (actuellement en béta) est une refonte majeure de la suite bureautique avec l'ajout de plusieurs nouvelles fonctions. Bien que très prometteuse cette nouvelle version suscite un large controverse auprès des utilisateurs de logiciels libres car elle renforce et élargit la dépendance envers Java.

Le nouveau module de base de donnée (Base) repose sur HSQLDB qui requiert Java. Le nouveau lecteur pour intégrer des vidéos et clips audio dans des documents dépend également de Java ainsi que tous les assistants de Writer (le module de traitement de texte).

Ce qui était jusqu'alors possible (utiliser OO.o sans Java) va devenir de moins en moins vrai et le caractère multi-plateforme de la suite bureautique va en pâtir.

Les réactions les plus virulentes accusent Sun (le principal contributeur d'OpenOffice.org) de machiavélisme afin de pousser sa technologie Java. D'autres utilisateurs déçus soulignent que plusieurs arguments de promotion d'OO.o par rapport à MicrosoftOffice deviennent caducs (la liberté ou le caractère multi-plateforme).

Du coté des distributions l'éventail des réactions est très large : des distributions commerciales comme Suse ou Mandrake fourniront une version non libre avec le JRE de Sun tandis que les versions librement téléchargeables ne comprendront pas ce support Java. RedHat (et donc Fedora) espère pouvoir utiliser une version libre de Java basée sur le compilateur libre GCJ et ainsi activer toutes les fonctions d'OpenOffice.org 2.0 (pour l'instant cela ne marche pas très bien et cela restera laborieux et difficile). Debian, Ubuntu ainsi que Gentoo n'ont pas d'autre option pour l'instant que de désactiver toutes les fonctions Java en attendant que GCJ avance.

En définitive cette affaire souligne le poids déterminant que Sun détient dans le développement d'OpenOffice.org et l'influence que cette firme exerce au moment des choix architecturaux des futures versions. La controverse actuelle est en tout cas extrêmement dommageable pour l'expansion d'OO.o qui semblait s'amplifier ces derniers temps.

Une divergence (fork) semblant improbable étant donné la taille et la complexité du projet la solution réside peut-être dans le soutien à apporter au projet GCJ ou aux suites libres communautaires (Koffice pour KDE et Abiword/Gnumeric pour Gnome).

Aller plus loin

  • # Un peu hors sujet

    Posté par . Évalué à -5.

    Comme on parle de HSQLDB, je voulais savoir si certains avaient déja mis en production cloudscape (ou derby comme il s'appelle désormais) sur de gros volumes ?

    J'avais bloggé la dessus il y a quelques temps suite à un entretien avec le mec de C-JDBC mais j'ai encore trouvé personne qui l'ait utilisé en production! (http://www.jroller.com/page/jonaslive/20041208#derby_seems_a_good_d(...)

    http://about.me/straumat

    • [^] # Re: Un peu hors sujet

      Posté par . Évalué à 0.

      Dans ma boite on est en cours de migration de hsqldb vers derby. C'est moins rapide mais plus robuste.
  • # Abiword et Gnumeric

    Posté par . Évalué à 8.

    C'est effectivement une bonne raison de promouvoir Abiword et Gnumeric, deux outils très légers et très efficaces, qui s'intègrent parfaitement dans l'environnement Gnome. (Abiword est aussi disponible en versions Mac et Windows)
    • [^] # Re: Abiword et Gnumeric

      Posté par . Évalué à 10.

      Et/ou de contribuer à GCJ/Classpath. Notons que Redhat (et compagnie...) fait un travail formidable de ce coté. Vivement un environnement (complètement) libre en Java.
      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 10.

        > Vivement un environnement (complètement) libre en Java.

        Je le répète encore, mais on y est presque. C'est l'un des grands objectifs de FC4.
        C'était déjà testable dans FC3 (non installé par défaut).

        Sun fout un peu le "bordel" avec ses brevets, mais ce qu'il faut, c'est s'"imposer". Tant pis si gcj n'est pas compatible à 100 % avec Sun (problème de brevet que _Sun_ a introduit).
        • [^] # Re: Abiword et Gnumeric

          Posté par . Évalué à 8.

          C'est quoi cette histoire de brevet ? Je croyais que Sun avait explicitement autorisé les implémentations libres de JVM ...
          • [^] # Re: Abiword et Gnumeric

            Posté par . Évalué à 7.

            Je ne connais pas les détails. Sun a des brevets avec des nouvelles fonctionnalités de la lib java. Les dernières doc java posent problème car si tu les consultes, c'est pour *tout* implémenter et tu n'as pas le droit de changer l'API (ce qui est incompatible avec le libre). Donc, ce qui faut faire, c'est ne pas regarder les dernières doc java. A moyen terme, c'est un fork gcj/java(de Sun) qui est garanti.
            • [^] # Re: Abiword et Gnumeric

              Posté par (page perso) . Évalué à 8.

              Il y a aussi la menace des brevets Microsoft : Sun et Microsoft ont un accord de non-attaque entre Microsoft Office et Sun StarOffice... mais pas pour OpenOffice.org...
              • [^] # Re: Abiword et Gnumeric

                Posté par . Évalué à 0.

                > Sun et Microsoft ont un accord de non-attaque

                Que Sun n'attaque pas MS, je m'en fous un peu :-)
                Par contre il ne faut pas que Sun puisse attaquer le libre. Donc il ne faut pas implémenter ses brevets.
                • [^] # Re: Abiword et Gnumeric

                  Posté par . Évalué à -3.

                  Perdu..., le commentaire précedent dit que MS peut attaquer openoffice en dehors du giron de SUN.
                  On peut imaginer :
                  - attaque d'un fork libre
                  - attaque de développeurs sur des contribs à OOO
                  ....
                  • [^] # Re: Abiword et Gnumeric

                    Posté par . Évalué à 1.

                    > Perdu..., le commentaire précedent dit que MS peut attaquer openoffice en dehors du giron de SUN.

                    Quoi perdu ?
                    Nÿco dit que MS ne peut pas attaquer Sun. Il ne dit pas que MS ne peut pas attaquer le libre.
                    J'ajoute que Sun peut attaquer le libre (via ses brevets, comme MS).
                    Donc, l'accord MS/Sun ne change rien pour le libre.
    • [^] # Re: Abiword et Gnumeric

      Posté par . Évalué à 10.

      deux outils très légers et très efficaces,
      bof, abiword met des plombes pour ouvrir de gros fichiers et j'ai eu de gros soucis pour imprimer des documents avec gnumeric (ca a finit en export excel, puis impression via openoffice.org).
      Il me semble aussi que gnumeric n'a pas de correcteur othographique.

      Ils sont prometteurs, mais manque de finition (je pense que c'est du au manque de contribueur/utilisateur)...
      • [^] # Re: Abiword et Gnumeric

        Posté par (page perso) . Évalué à -4.

        "Il me semble aussi que gnumeric n'a pas de correcteur othographique."

        Ca fait v'la le tps que aspell est intégré à abiword.

        Concernant les gros fichiers, OOo à le même defaut (c bien le xml mais c plus long).
        • [^] # Re: Abiword et Gnumeric

          Posté par . Évalué à 3.

          gnumeric != abiword...

          sinon OOo est quand meme plus rapide 5-10 secondes via 30-60 secondes

          Tant que j'y suis c'est quoi les equivalents pour les presentations et le dessins ?
          • [^] # Commentaire supprimé

            Posté par . Évalué à 1.

            Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Abiword et Gnumeric

            Posté par . Évalué à 4.

            Pour le dessin, tu as inkscape en vectoriel qui est excellent, un fork réussi de sodipodi (qui n'évolue plus vraiment) et qui intègre de plus en plus de trucs.

            Pour les présentations j'avais croisé un truc permettant de faire des présentations en html, tu faisais ton texte et il ajoutait les boutons de navigation. Minimal, mais suffisant pour la plupart des présentations. J'ai par contre oublié le nom.
            • [^] # Re: Abiword et Gnumeric

              Posté par (page perso) . Évalué à 4.

              Pour les présentations j'avais croisé un truc permettant de faire des présentations en html, tu faisais ton texte et il ajoutait les boutons de navigation.
              DocBook je suppose. Je sais qu'il y a aussi des "diaporama" à base de SVG.
            • [^] # Re: Abiword et Gnumeric

              Posté par . Évalué à 4.

              Dans le genre "présentation depuis un simple texte formaté", il y a MagicPoint, que j'ai vu utilisé au Fosdem par quelques personnes. Ça a ces limites comparé à (par exemple) du Latex/Beamer, mais ça a l'air de bien faire son job pour les besoins simples :
              http://member.wide.ad.jp/wg/mgp/(...)

              Il y a aussi S5 qui a l'air sympa, basé lui sur XHTML et CSS :
              http://linuxfr.org/2004/10/14/17436.html(...)
              http://www.meyerweb.com/eric/tools/s5/(...)
              • [^] # Re: Abiword et Gnumeric

                Posté par (page perso) . Évalué à 3.

                Pour les présentation, y'a kpdf aussi maintenant :)

                avec kde, n'importe quel appli sait faire du pdf.
                • [^] # Re: Abiword et Gnumeric

                  Posté par . Évalué à 0.

                  Tu veux dire que dans Konqueror il y a le menu "exporter en pdf" ?
                  • [^] # Re: Abiword et Gnumeric

                    Posté par . Évalué à 2.

                    Non, Menu fichier -> Imprimer
                    puis dans kprinter, choisi "Imprimer dans un fichier (PDF/Acrobat)"

                    </ troll >
                    • [^] # Re: Abiword et Gnumeric

                      Posté par . Évalué à 2.

                      <t'as dit>
                      </ troll >
                      </t'as dit>

                      Même pas vrai, ça marche aussi sous gnome!
                      • [^] # Re: Abiword et Gnumeric

                        Posté par . Évalué à 2.

                        En fait ça marche dans tous les programmes qui peuvent imprimer.
                        Puisque sur un système Unix l'impression est basée sur postscript, imprimer dans un fichier te donne un fichier postscript. Ensuite il n'y a plus qu'à faire un ps2pdf.

                        Et pour les programmes qui permettent de changer la comande d'impression (par exemple mozilla) tu peux remplacer le bon vieux lpr par kprinter.
                  • [^] # Re: Abiword et Gnumeric

                    Posté par . Évalué à 2.

                    Presque, il suffit d'imprimer vers un fichier pdf
                    • [^] # Re: Abiword et Gnumeric

                      Posté par . Évalué à 0.

                      Franchement, je ne m'attendais pas à une réponse positive :-)
                      Le fait d'"imprimer vers un fichier pdf" est un détail.
              • [^] # Re: Abiword et Gnumeric

                Posté par . Évalué à 2.

                Le pb de ces outils c'est qu'il faut fairepreparer les presentations a la main, ce qui n'est pas forcement evidenet surtout qd on est pressé.

                Et dans ce cas autant faire du Latex/Beamer et l'exporter en pdf pour la pres.
      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 9.

        Ils sont prometteurs, mais manque de finition (je pense que c'est du au manque de contribueur/utilisateur)...


        Justement, ils sont prometteurs, donc nécessitent des contributeurs et des utilisateurs (des patches, des bug reports, des manuels...).

        Si tout le monde les laisse tomber, alors ils n'auront aucune raison de mûrir...

        Ce serait une victoire pour le logiciel libre si de tels logiciels arrivaient au niveau d'OpenOffice.org car jusqu'ici j'entends bien des gens dire «le logiciel libre, c'est bien, mais les vrais logiciels libres qui marchent sont ceux qui ont été produits sur le modèle proriétaire...» et ça me fait toujours mal...
        • [^] # Re: Abiword et Gnumeric

          Posté par . Évalué à -2.

          Ce serait une victoire pour le logiciel libre si de tels logiciels arrivaient au niveau d'OpenOffice.org


          Ah non. Heureusement qu'il existe un traitement de texte utilisable par madame michu sur Linux.
        • [^] # Re: Abiword et Gnumeric

          Posté par . Évalué à -2.

          > Ce serait une victoire pour le logiciel libre si de tels logiciels arrivaient au niveau d'OpenOffice.org

          OpenOffice.org *est* un logiciel libre.
    • [^] # Re: Abiword et Gnumeric

      Posté par . Évalué à 10.

      Et beh.

      Deja qu'on a du mal a faire passer les "profanes"
      de la suite MS Office a OOo.

      si en plus au bout de 6 mois on leur dit : non finalement
      tu vas encore utiliser autre chose : on va migrer
      parce que ya eu scission au sein du parti.

      ....
      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 5.

        Certes. Mais enfin OpenOffice est une usine à gaz depuis le début, et il n'était pas difficile d'imaginer que l'hégémonie de Sun allait poser des problèmes vis-à-vis du mode de développement. Le truc c'est que l'ensemble de la communauté du libre a encensé OpenOffice en faisant l'impasse sur ces deux gros écueils, ce qui conduit à la situation actuelle où Abiword et Gnumeric ont l'air de petits outsiders alors qu'ils étaient là depuis bien plus longtemps qu'OpenOffice, et qu'ils n'ont jamais cessé d'être des logiciels intéressants (c'est pas comme si on comparait Mozilla à links).

        Donc, oui, on paye le prix de cet enthousiasme un peu naïf et débridé, et de ce délaissement de deux projets prometteurs. Mais c'est de notre faute.
      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 5.

        Si l'application est meilleure (plus rapide par exemple), sans aucune hésitation je dis OUI.
        La distance entre le double clic et la permière lettre reste impressionnante sous OpenOffice comparé à MS Office.

        J'ai honte des fois quand je montre ca à mes "profanes".
    • [^] # Re: Abiword et Gnumeric

      Posté par . Évalué à 4.

      C'est effectivement une bonne raison de promouvoir Abiword et Gnumeric

      Sans oublier KOffice dont la version 4 utilisera nativement le format OOo. Pas besoin de Java. D'où l'utilité de porter les libs KDE sous d'autres plateformes (Windows).

      Pour en revenir à l'utilisation de Java, j'ai un peu de mal à en voir la nécessité. Autant pour JDBC, ça se comprend. Pour XSLT, why not. Apache propose pas mal d'outils en Java, notament pour manipuler du SVG. Mais pourquoi ne pas utiliser LibXML2 qui est une lib native, multi-plateforme, et l'une des plus complètes et conformes aux standards ? Quand à Java pour les wizards de Writer, là c'est un peu portnawak. Le reste de l'interface vit très bien sans Java alors pourquoi quelques malheureuses boites de dialogue auraient-elles besoin de ça ? Pour faire des effets-3D-qui-font-bander-papy ?
      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 6.

        Pourquoi ? simplement que la seule personne qui a proposé ses services pour faire ce genre de boulot était un développeur Java. C'est expliqué en détail dans un post plus ci-dessous.

        C'est con parfois la vie !
    • [^] # Re: Abiword et Gnumeric

      Posté par . Évalué à 0.

      Comme tous les logiciels autour de Gnome Abiword et Gnumeric sont certe depuis des années prometteurs mais n'ont pas encore atteint un niveau de finition et de fonctionalités nécessaire pour une utilisation professionnelle.

      • [^] # Re: Abiword et Gnumeric

        Posté par . Évalué à 9.

        J'ose espérer que c'est une blague, en tout cas pour Gnumeric ?

        Nan parce que ma femme, qui est comptable, n'utilise peut-être pas toutes les fonctionnalités d'Excel, mais ce qui est sûr, c'est qu'elle l'utilise toute la journée au boulot et intensément.

        En bref : elle dit que Gnumeric est largement au-dessus de tout ce qu'elle a essayé sous Linux jusqu'à présent, dixit elle-même : "c'est mieux qu'Excel !!!", et elle utilise Excel de manière professionnelle. Alors bon, c'est qu'une anecdote, mais ça ne fait que corroborer tout ce que j'entends sur les fonctionnalités de Gnumeric, et va à l'encontre de ce que dit le post parent.

        En plus long :
        Ma femme utilise beaucoup les tableurs parce que ça doit être ce qu'elle connaît (et comprend) le mieux en informatique. Elle a utilisé le tableur d'OOo pour son boulot et pour elle. Elle m'a fait tout un tas de reproches sur le tableur d'OOo, bon OK, elle a connaissance de la doc (en français), et elle m'avait avoué qu'elle avait pas envie de changer tout ce qu'elle savait. Elle utilisait KSpread pour ses fichiers perso et disait que c'était suffisant, mais que tout marchait pas bien.
        Récemment passé en KDE 3.4 et Gnome 2.10, les applis sont maintenant mélangées dans les menus des deux DE. Un matin de la semaine dernière, elle m'appelle tout excitée : "regarde ! J'ai trouvé un super tableur, ça fait tout comme Excel, c'est même mieux, y a pas tel bug !". Les yeux ébahis, je lui demande comment elle a trouvé ce programme. Elle me montre alors le menu Bureautique de KDE, avec Tableur Gnumeric (ou un truc comme ça) tout en bas du menu.
        Au passage, vu qu'elle utilise aussi Galeon comme navigateur, ça finit de casser à mes yeux les deux arguments suivants anti-LL :
        - Il est très difficile de trouver à quoi sert une appli dont on ne connaît pas le nom sous Linux (j'utilisais Gnumeric parce que je suis sous Gnome, mais je lui avais pas dit, maintenant, c'est terminé pour KSpread :( )
        - Les applis Gnome s'intègrent très mal dans KDE et vice-versa. Moi je ne suis pas une référence quand je dis que je ne vois pas de différence en utilisant mp3Kult sous Gnome, mais ma femme qui a utilisé Gnumeric (et Galeon) sans souci, sans même se rendre compte qu'il y avait des choses différentes, ça en dit long. Ah si, elle a quand même bloqué sur l'enregistrement de fichier : elle cherchait comment enregistrer dans un sous-répertoire de son HOME (faut cliquer la petite flèche, le texte explicatif à côté est encore trop technique pour elle).
        - Ma femme, utilisateur lambda typique qui n'y comprend rien à l'informatique, n'a jamais été aussi productive à la maison, que depuis Janvier 2001 où j'ai finit de basculer sous Linux, venant de Windows (moi aussi, mais on m'accuserait d'être fanatique).
        - Gnumeric est très loin devant le tableur d'OOo et au moins égal à Excel pour la plupart des utilisateurs professionnels non programmeurs (ma femme fait des petites macros pas trop compliquées)
        • [^] # Re: Abiword et Gnumeric

          Posté par . Évalué à 3.

          Oui, Gnumeric est bien, mais il lui manque à mes yeux une fonctionnalité essentielle pour un tableur moderne : les tableaux croisés dynamiques (ou l'auto-pilote de données si vous préférez).

          C'est très puissant, et c'est surtout en passe de devenir une des interfaces standard vers les bases OLAP (au passage, à part Mondrian, en java, pas d'OLAP libre à l'horizon).

          A mon avis, les alternatives à OOo sont très très loin de faire le compte. Du coup, oui pour un énorme travail sur GNU Classpath !
      • [^] # Re: Abiword et Gnumeric

        Posté par (page perso) . Évalué à 1.

        Je ne suis pas d'accord.
        Ces deux applications sont très bien faite.

        Le seul reproche, c'est qu'il n'existe pas (à ma connaissance) de format de fichier ne provenant pas de la suite MS Office compatible entre les applications de bureautique libre.

        Voila :-)
    • [^] # Re: Abiword et Gnumeric

      Posté par (page perso) . Évalué à 2.

      N'oublions pas KWord, KSpread, KPresenter et le prometteur Kexi :-)
      http://www.koffice.org/(...)
  • # gcj

    Posté par . Évalué à 10.

    > basée sur le compilateur libre GCJ et ainsi activer toutes les fonctions d'OpenOffice.org 2.0 (pour l'instant cela ne marche pas très bien et cela restera laborieux et difficile).

    Si c'est pour faire référence au mail gcj de l'article de Newsforge, il date des premiers essais OOo/gcj. Au début de FC4 OOo 2.0 n'était programmé (dépendance avec le planning de OOo).
    Le planning de OOo 2.0 a été précisé, la décision d'avoir OOo 2.0 dans FC4 a été prise, la mise au point gcj avec OOo a débuté.

    Actuellement ça marche (j'ignore si tout est fonctionnel) ; xsl ; odbc.

    C'est configuré avec :
    %configure --with-java=gij --disable-epm --enable-libart --enable-gtk --enable-gnome-vfs --enable-openldap --enable-cups --enable-libsn --enable-fontconfig --disable-fontooo --with-system-libs --with-system-python --with-system-mozilla --with-system-boost --without-system-mspack --without-system-sablot --without-system-nas --without-system-sndfile --without-system-portaudio --without-fonts %{withlang}

    La version 1.9.88 devrait arriver demain dans RawHide (dans le tuyau du cvs).
    Donc "laborieux et difficile" c'est à voir.
    • [^] # Re: gcj

      Posté par (page perso) . Évalué à 9.

      >> Si c'est pour faire référence au mail gcj de l'article de Newsforge

      oui effectivement je m'appuyais la-dessus pour faire cette remarque.
      Maintenant même si GCJ avance bien et que OO.o 2.0 builde sans problème y'a quand même des questions à se poser : quid de futures fonctions basés sur Java et que GCJ ne pourra pas supporter immédiatement ? quid de la mainmise de fait de Sun ? quid des problèmes de mémoire et de vitesse induits par Java sur des configurations modestes ?
      De façon générale les décisions sur le futur d'OO.o dépendent d'une grande multinationale qui n'aime pas trop Linux....sachant qu'OO.o est devenu un étendard du libre c'est génant.
      • [^] # Re: gcj

        Posté par . Évalué à 8.

        sachant qu'OO.o est devenu un étendard du libre c'est génant.
        Il est dévenu un étendard du libre grâce à la bonne volonté de SUN.. faut pas l'oublirer non plus. Depuis le début, on sait que ca vient de chez sun...

        http://about.me/straumat

      • [^] # Re: gcj

        Posté par . Évalué à 2.

        > quid de futures fonctions basés sur Java et que GCJ ne pourra pas supporter immédiatement ?

        Excellente question. Ça dépend de la bonne volontée de Sun. Au pire il y aura un mini-fork (java ne se révolutionne pas tous les jours).

        > quid des problèmes de mémoire et de vitesse induits par Java sur des configurations modestes ?

        Ici ça marche correctement avec gcj. Tu devrais faire un essai. Gcj a maintenant un niveau tout a fait respectable (même s'il reste encore du boulot). Avec Gcj (et classgnu) ont fait touner assez confortablement le gros et 100 % java eclipse en version native. De plus eclipse utilise gij pour java (si tout est bien configuré).

        Franchement, tu devrais faire un essai. Enfin, gcj a une marge de progression (vitesse et mémoire) beaucoup plus importante que le java "classique".
        • [^] # Re: gcj

          Posté par . Évalué à 2.

          Tu l'as compilé toi même ton eclipse/gcj ? parce que les build fournies pour debian annoncées il y a quelque jours dans les journaux c'était pas trop ca :
          - comportement bizarre,
          - plus de 250Mo de mémoire résiduelle
          - lenteur (à ma très grande suprise).

          Ca marchait à peu près bien quand je lançais eclipse (buildé gij hein) avec la JVM de sun, mais avec gij, rien à faire, totalement inexploitable...

          Mais si t'as des tuyaux je suis prenneur.
          • [^] # Re: gcj

            Posté par . Évalué à 1.

            > Tu l'as compilé toi même ton eclipse/gcj ?

            Non. Il est par défaut dans FC4T1 (va être probablement déplacé dans Fedora Extra).

            > - comportement bizarre

            Je ne suis pas un utilisateur régulier d'éclipse. D'ailleurs je ne connais pas bien java. Je commence à m'y intéresser car il y a enfin une solution libre, viable, supporté (dans le contexte d'une distribution) et sans prise de tête. Eclipse compilé avec gcj est fournit par Red Hat depuis RHEL 3. Donc, ça ne doit pas être trop pourri.

            > - plus de 250Mo de mémoire résiduelle

            Depuis un chroot (le chroot c'est pour passer sous FC4T1), avec eclipse-ecj et eclipse-jdt + évidemment toutes les dépendances :
            [admin@one ~]$ free
            total used free shared buffers cached
            Mem: 517176 498396 18780 0 9180 334116
            -/+ buffers/cache: 155100 362076
            Swap: 1702392 163816 1538576
            [admin@one ~]$ eclipse &
            [1] 31151
            [admin@one ~]$ free # après le chargement d'Eclipse
            total used free shared buffers cached
            Mem: 517176 469124 48052 0 7440 259868
            -/+ buffers/cache: 201816 315360
            Swap: 1702392 163812 1538580

            Temps de chargement de 28 secondes si rien est en cache (relativement vieux disque de 20 Go), 10 secondes si c'est en cache. Athlon XP 1600 - 512 Mo.

            Sûr que ça doit bouffer plus de mémoire avec un projet ouvert.

            > - lenteur (à ma très grande suprise).

            Pas un foudre de guerre. Mais ça roule.

            > mais avec gij, rien à faire, totalement inexploitable...

            Je n'ai pas connaissance que Red Hat n'ait jamais tenté d'utiliser gij. En fait, ils voulait eclipse avec un java libre. Après quelques tests (et selon mes souvenirs car c'est vieu) ils se sont orienté vers gcj (compilation en natif d'Eclipse).

            > Mais si t'as des tuyaux je suis prenneur.

            Si c'est pour évaluer le potentiel, le mieux est d'installer FC4T1. Néanmoins je te conseille d'attendre FC4T2 car la T1, comme toute T1 qui se respecte, est assez bugguée.
      • [^] # Re: gcj

        Posté par . Évalué à 4.

        > quid des problèmes de mémoire et de vitesse induits par Java sur des configurations modestes ?

        OOo a beau être en C++, il est déjà hors de portée des configurations modestes (50Mo au lancement).
  • # Si çà peut booster GCJ

    Posté par . Évalué à 10.

    Si au final, çà a pour conséquence de booster le projet GCJ. çà ne sera pas un mal.

    Java est la technologie qui embauche le plus et qui reçoit le plus d'investissement de la part des entreprises.

    Il est temps que cette techno coupe son cordon ombilical avec Sun qui devient trop encombrant.
    • [^] # Re: Si çà peut booster GCJ

      Posté par . Évalué à 8.

      Tout à fait d'accord!
      Des projets libres tels que Hibernate, C-JDBC, Spring, JOnAS, XDoclet, XMLBean, JUnit (et JUnitScenario;)), Ant, Eclipse... font de Java une plateforme de développement génial! Il manque plus qu'à libérer la jvm!

      http://about.me/straumat

      • [^] # Re: Si çà peut booster GCJ

        Posté par . Évalué à 1.

        > Il manque plus qu'à libérer la jvm!

        ???
        Ici je fais :
        - yum install java-1.4.2-gcj-compat

        Certe, certains programmes qui utilisent les dernières trouvailles brevetés de Sun ne marcheront pas. C'est à gcj de s'"imposer".
        • [^] # Re: Si çà peut booster GCJ

          Posté par . Évalué à 5.

          En fait, je voulais dire que sun devrait librer java :)
          Au passage, le serveur d'applications J2EE JOnAS fonctionne sous gcj ;) merci redhat

          http://about.me/straumat

    • [^] # Re: Si çà peut booster GCJ

      Posté par . Évalué à 2.

      Grâce à «Journal de Décideurs Pressés»(c)(tm) : Ton Java il est beau, il est grand, il est fort.
      Mais au final, ce sont les admins qui s'emm^Hbète à gérer ce truc afin que la machine de production ne plante pas pour la 10ème fois dans le mois.
      • [^] # Re: Si çà peut booster GCJ

        Posté par . Évalué à 4.

        problème non constaté ici... peut etre que les admins de ta boite devrait se mettre au gout du jour ? on développé en java depuis 4 ans.. ( on écrit même des bouquins dessus!) et nos applis tournent bien... il ya meme une application qu'on a fait en belgique pour un gros consortium dans les assurances et qui tournent depuis 2 ans sans jamais avoir planté (pourtant elle traite un paquet de demandes webservices, mail et ftp, http post)

        http://about.me/straumat

        • [^] # Re: Si çà peut booster GCJ

          Posté par . Évalué à 6.

          Bizarrement, à chaque fois qu'on rencontre Java chez nos clients (tous différents) ils ont toujours de problèmes, soit de lourdeur, soit de plantage, soit des deux.
          Et les devs Java disent toujours que c'est un problème du à la plateforme ...
          Mais bon, je dois me tromper aussi ...
          • [^] # Re: Si çà peut booster GCJ

            Posté par . Évalué à 1.

            Sûrement car comme pour le commentaire juste au dessus, nous bossons dans notre boite avec Java depuis plus de 5 ans et cela sans problème (frontal internet, intranet, serveur d'appli, batch de traitement, ...).
            Les problèmes de perf rencontrés étaient toujours soit de notre faute (algorithme , bug, ...) soit un problème d'optimisation de requete sql.
      • [^] # Re: Si çà peut booster GCJ

        Posté par (page perso) . Évalué à 4.

        Faut demander aux programmeurs de pas programmer comme des porcs (éviter svp d'utiliser des patterns lourdingues quand y'a pas besoin, apprendre quand utiliser StringBuffer et quand ne pas le faire !, etc ...), et d'apprendre comment fonctionne un classloader avant de s'appuyer aveuglément sur les softs ASF style "Apache Jakarta Commons Logging" (quelle daube ! aussi log4j). Quand vous avez des programmes qui bouffent de la mémoire de façon "inexpliquable" (!), regardez dans ce sens. Et arrêtez SVP de lécher les bottes de l'ASF.

        Avec des programmes "maison" qui n'utilisent pas de librairies de daube, je peux vous assurer que la mémoire est stable, et y'a pas besoin de redémarrer le prog, ou reboot, même sous charge correcte ;-)
    • [^] # Re: Si çà peut booster GCJ

      Posté par . Évalué à 7.

      > Java est la technologie qui embauche le plus

      comme les technos MS a la fin des annees 90 apres l'apparition de NT4. Ouais . Je connais le resultat...
      • [^] # Re: Si çà peut booster GCJ

        Posté par (page perso) . Évalué à 9.

        On peut rajouter le développement web a l'époque start-up....

        Bon, ça fait parti du métier.... mais quand je vois un pote carreleur qui tourne à 17kf net par mois, et les salaire du moment en informatique, je regrette d'avoir choisi l'info, parce que le carreleur, s'il doit se tenir au courrant, il ne doit pas tout réapprendre tous les 3 ans au risque de finir au RMI ...
        • [^] # Re: Si çà peut booster GCJ

          Posté par . Évalué à 3.

          y a encore pire.

          Discute un peu avec un laveur de carreaux ... oui oui le laveur de carreaux là en bas avec sa mob et sa petite echelle ...

          Tu sera surpris de son salaire ...
          • [^] # Re: Si çà peut booster GCJ

            Posté par . Évalué à 3.

            Ceci dit, j'ai lu dans un journal ("Metro") qu'en Belgique, laveur de carreaux est le métier le plus dangereux! Et oui! plus dangereux que pompier, militaire, etc...

            De facon générale, je crois que "artisan" est une classe de métier très intéresante pour qui a du courage, et même sans avoir étudié longtemps. Je sais que les électriciens et les plombiers ne sont pas en reste question salaire. Les plombiers par chez moi ont d'ailleurs souvent des listes d'attente de quelques mois!
        • [^] # Re: Si çà peut booster GCJ

          Posté par . Évalué à 10.

          il ne doit pas tout réapprendre tous les 3 ans au risque de finir au RMI ...

          Les développeurs Java sont depuis longtemps au RMI....
          http://java.sun.com/products/jdk/rmi/(...)

          (/me --->[] )
  • # Mais bon sang !

    Posté par . Évalué à 7.

    Quand comprendra t on que Sun n'en a rien a faire des logiciels libres ?

    Il veulent faire du blé , un point c'est tout .
    Et pour eux ca consiste à promouvoir java pour vendre leurs machines et leurs services.

    Rien d'anormal a cela , mais c'est comme ca. On dirait que certains croient au pere noel !

    Au fil du temps et des ameliorations successives de java et des outils java , le fait que ce ne soit pas libre est devenu la seule et unique raison de pourquoi je n'y touche pas (*) et pourtant cette raison suffit a elle seule ! C'est dire !



    (*): en tout cas pas de mon propre chef ! faut bien vivre... mais heureusement c'est rare.
    • [^] # Re: Mais bon sang !

      Posté par . Évalué à 4.

      Tiens pour information, la communauté peut désormais contribuer officiellement des patches pour l'API de J2SE. Ce n'est pas encore de la licence libre qui fait plaisir à tout le monde mais c'est une avancée intéressante.

      Et si cela peut te rassurer un peu : http://www.sunsource.net/(...)
      • [^] # Re: Mais bon sang !

        Posté par . Évalué à 6.

        Tiens pour information, la communauté peut désormais contribuer officiellement des patches pour l'API de J2SE

        Tu veux dire qu'on peut contribuer bénvolement à un produit d'une société commerciale dont les certifications sont payantes ? Quelle grandeur d'âme.
        • [^] # Re: Mais bon sang !

          Posté par . Évalué à 3.

          Ou tout bêtement contribuer pour aider la grande quantité de projets Open Source et libres utilisant Java...
          • [^] # Re: Mais bon sang !

            Posté par . Évalué à 7.

            Le problème c'est que la licence de Sun stipule que, si on a lu le(s) fichier(s) au(x)quel(s) on a contribué (cas plutôt courant ;), on n'a plus le droit de contribuer à une fonctionalité équivalente d'un logiciel tiers (un LL par ex ...).

            Donc effectivement, l'appel à contribution de Sun, c'est plutôt gonflé.
            • [^] # Re: Mais bon sang !

              Posté par . Évalué à 1.

              Donc ceux qui développent gcj, ne doivent pas lire les versions récentes de la doc de Java. C'est un vrai problème.
            • [^] # Re: Mais bon sang !

              Posté par . Évalué à 0.

              Ben figure-toi que j'avais voulu participer à Classpath mais qu'ayant lu les sources de Sun dans le passé, je ne pouvais pas (chose con mais ça sert énormément quand on hérite de certaines de leurs classes :). Puisque je ne peux pas m'intéresser à Classpath, autant aider le J2SE "officiel" non ? Ou alors peut être que je devrais rien faire du tout.
    • [^] # Re: Mais bon sang !

      Posté par (page perso) . Évalué à 3.

      Il veulent faire du blé , un point c'est tout .

      Dans leur état actuel (Sparc, Solaris...) je pense surtout qu'ils cherchent à survivre :) ils sont pas mal dans la merde les petits.
      • [^] # Re: Mais bon sang !

        Posté par . Évalué à 1.

        > Dans leur état actuel (Sparc, Solaris...) je pense surtout qu'ils cherchent à survivre :) ils sont pas mal dans la merde les petits.

        Oui, enfin en même temps, quand on voit la (très) rapide dégradation de ces produits et des services associés, il faut bien admettre qu'il l'on un peu cherché...

        Pour le Sparc, il suffit de le mettre face à un Sparc64 (Fujitsu) pour voir la différence. Pour le système, Solaris10 sur une v20z est à pleurer comparé à un linux sur la même machine.

        Et pour le service, une journée ouvrée pour avoir un début de réponse suite au plantage d'une machine "critique"...

        Faut pas s'étonner que beaucoup quittent le navire : à coté, c'est pas forcemment plus fiable, mais c'est plus performant pour bien moins cher...
      • [^] # Re: Mais bon sang !

        Posté par . Évalué à 4.

        C'est encore pire. Une entreprise qui panique peut se transformer très vite en le pire des requins (cf. SCO).
  • # Sun a toujours le mauvais rôle

    Posté par . Évalué à 10.

    Certains vont un peu vite en besogne. Peut-être que Sun est responsable de cette intrusion de Java dans la base de code d'OOo, mais il s'agit peut être d'un choix délibéré des développeurs. Décidément, le mal est vu là où ça en arrange certains. Bref, sans informations plus pertinentes, ne nous avançons pas trop.

    Concernant les remarques sur le fait que Sun semble contrôler le projet, je suis très embêté. Sun a tout de même racheté StarOffice pour ouvrir le code source. Sun paye tout de même des développeurs pour travailler sur ce projet. Et si je ne m'abuse, ils fournissent une quantité non négligeable du travail. Il est amusant de voir que l'on critique Sun pour cela tandis que bien souvent on reproche à Sun de ne rien faire pour l'Open Source et le libre.

    Bien sûr cela ne change rien au problème de la disponibilité de Java sur certaines plateformes (quoique tu peux l'avoir sur PowerPC avec MacOS X ;-) mais j'ai un peu de mal à lire ce genre de choses sans me dire qu'il y a quand même beaucoup beaucoup de râleurs dans cet univers (oui je sais c'est comme ça qu'on fait avancer les choses, etc.).

    Enfin, personnellement, je continuerai à utiliser et à recommander OpenOffice.org.
    • [^] # Commentaire supprimé

      Posté par . Évalué à 5.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à 2.

        > le java c'est rigolo de voir que pour avoir le plugin dans mozilla

        Le plug-in java avec gcj est prévu. Ça marche déjà mais il y a des problèmes de sécurité (ça marche comme un programme java et non comme une applet niveau sécurité). Red Hat envisage de corriger ça avec SeLinux. Peut-être pour FC4, mais plus probablement pour FC5.
        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par . Évalué à -1.

            > pour le faire fonctionner sur amd64 mis a part dans un chroot

            Avec rpm, tu n'as pas besoin de chroot.
            Le portage vers amd64 est en cours. Probablement après la sortie de OOo 2.0.

            > idem avec OsX ou il faut passer absolument par X11

            A part tout critiquer, tu fais quoi ? Tu veux que Sun fasse tout. Ils ne peuvent pas. Perso, je suis très content avec OOo. OOo 2.0 est une belle amélioration.
          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par . Évalué à 3.

            Pour OS X, va voir du côté de NeoOffice : http://www.neooffice.org(...)

            Mais gag, ils utilisent du Java partout pour arriver à faire de OO une appli plus ou moins native.
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à 4.

        > Dans le meme temps le pyhton existe

        Tu peux utiliser python avec OOo.
        Si tu veux remplacer le code java par du code C ou python, je crois que personne ne sera contre.
    • [^] # Re: Sun a toujours le mauvais rôle

      Posté par . Évalué à 7.

      Enormement de boites aiment l'open source et le libre tant que ca peut servir leurs interets.
      Sun a trouvé un moyen d'aimer l'oss et le libre par OOo : en les faisant venir à java et en se rendant incontournable ! Ca c'est un point qui sert leurs interets.

      L'un des avantages de base du libre est de pouvoir s'affranchir de dépendances obligatoires propriétaires.
      Dans l'idéal, ca doit se faire à tous les niveaux (pas seulement l'OS).
      Pour OOo c'est de moins en moins le cas dirait-on. Sun s'est débrouillé pour qu'on dépende de lui pour certaines fonctionnalités.

      Et en cas de problème majeur, c'est là qu'on est content d'avoir au moins un standard pour le format de données utilisable par d'autres softs au moins aussi libres que OOo (voire plus).
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à 10.

        Pas de panique. Selon un dev. de Classpath, il semble possible de faire tourner Oo 2. avec un environnement java libre : http://spindazzle.org/green/(...)

        De toute manière le libre cela se mérite, il ne suffit pas de le décréter. C'est à la communauté libre de prendre son avenir en main pour produire un environnement libre en Java de qualité (et non de chialer/crier sur Sun qui ne fait pas comme elle le souhaiterait). Si certain, ici et ailleurs codaient autant qu'ils gueulaient, il est probable que bcp de projets libres seraient plus avancés.
    • [^] # Re: Sun a toujours le mauvais rôle

      Posté par (page perso) . Évalué à 6.

      c'est juste que moi je vois pas vraiment l'intérêt de faire chier le monde en liant OO.o avec Java aussi fortement.
      Si encore c'était pour avoir des trucs révolutionnaires et impossible à trouver ailleurs....mais là c'est un peu grotesque. Pour le module Base de données et sachant qu'on a toujours la possiblité d'avoir une base MySQL ou PostgreSQL ils auraient pu choisir SQLite comme base embarquée(petit et léger). Pour les wizards (assistants) de Writer quel est la nécessité de réécrire tout en Java ?

      Ca ressemble vraiment à du forcing sans justification solide.
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par (page perso) . Évalué à 2.

        Ils ont pas à se justifier : le fait est que c'est les mecs de SUN qui font tout le boulot, ils le font avec les technos qu'ils veulent... Si les utilisateurs râlent, ben qu'ils prennent leurs doigts et qu'ils codent.
        Je rappelle que Java n'est jamais indispensable, il ne va pas apporter de feature qui tue à OOo. Par contre il peut grandement améliorer la productivité des codeurs (syntaxe, gestion mémoire, portabilité, libs, etc.)
        • [^] # Commentaire supprimé

          Posté par . Évalué à 0.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par . Évalué à 2.

            mouais... c bidon ce que tu dis, le "ca devient de pus en plus courant" me prait bien galvaudé, pour donner des confs et assister à d'autres, je peux te dire que j'ai jamais vu ce truc être utilisé!

            http://about.me/straumat

        • [^] # Re: Sun a toujours le mauvais rôle

          Posté par . Évalué à 3.

          Par contre il peut grandement améliorer la productivité des codeurs (syntaxe, gestion mémoire, portabilité, libs, etc.)

          Mais justement, c'est la portabilité qui pose problème avec java! (enfin, entre autres problèmes).
          Je m'abstiendrai de faire une blague pour ce qui concerne la "gestion de la mémoire" ;)
          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par (page perso) . Évalué à 5.

            Même si c'est pas parfaitement portable, cela a l'avantage d'être toujours plus portable que du C/C++ qu'il faudra recompiler sur chaque plateforme (voir adapter quand on change de plateforme matérielle).

            Pour la gestion mémoire, il y a 2 types de raisonnement :
            - ceux qui disent que la gestion mémoire est tellement importante qu'il ne faut pas laisser la machine s'en occuper.
            - ceux qui disent que la gestion mémoire est tellement importante qu'il ne faut pas laisser le programmeur s'en occuper.

            Reste que c'est une grosse perte de temps et de bugs potentiels, alors il faut mieux s'en passer quand c'est possible.

            Après c'est pas pour autant qu'il ne faut pas avoir une gestion "économe" de la mémoire, en recyclant par exemple les objets ou en aidant le GC quand c'est possible (et pertinent).
            • [^] # Re: Sun a toujours le mauvais rôle

              Posté par . Évalué à 9.

              Même si c'est pas parfaitement portable, cela a l'avantage d'être toujours plus portable que du C/C++

              Non, justement, tous les messages disent le contraire. Le problème c'est que la JVM et les libs officielles (celles qui implémentent toute la spec) sont disponibles pour beaucoup moins de plateformes que, par exemple, gcc et la glibc.

              Donc, oui, le C/C++ il faut le recompiler, mais l'avantage c'est qu'on a des outils libres pour le faire sur la plupart des plateformes.
              • [^] # Re: Sun a toujours le mauvais rôle

                Posté par (page perso) . Évalué à 2.

                Bah gcj est en C/C++ ?
                Donc portable sur autant de plateforme qu'il y a de compilateur C/C++ non ?

                Donc en l'état actuel c'est plutôt embêtant effectivement ce choix de Java sans avoir semble-t-il tenu compte des VM libres (surtout pour un projet libre, j'avoue ne pas vraiment capter sur ce coup là), mais si GCJ tient ses promesses... Wait & See FC4.
                • [^] # Re: Sun a toujours le mauvais rôle

                  Posté par . Évalué à 2.

                  Bah gcj est en C/C++ ?

                  Il y a quand même un certain nombre de personnes qui semblent dire que gcj et les bibliothèques libres n'implémentent pas la totalité des specs Java. Tu devrais peut-être argumenter sur ce point, si tu penses que c'est faux...
                  • [^] # Re: Sun a toujours le mauvais rôle

                    Posté par (page perso) . Évalué à 2.

                    Ah je penses pas que c'est faux du tout, c'est un fait, gcj n'implémente pas tout.
                    Je voulais juste dire que niveau portabilité si gcj supporte correctement OOo, il suffit que gcj soit porté et le tour est joué.
            • [^] # Re: Sun a toujours le mauvais rôle

              Posté par . Évalué à 8.

              Même si c'est pas parfaitement portable, cela a l'avantage d'être toujours plus portable que du C/C++

              Quand je disait portable, je ne parlais pas du "langage Java" mais de de la seule implementation complete qui est accessoirement l'environement nécessaire pour faire tourner Ooo (les hacks red hats ne sont encore que des hacks), à savoir l'environement Java de Sun.

              Exemples: Pas de JDK 1.5 sous OpenBSD (et je crois qu'il faut de l'émul linux pour les autres BSD). Pas de JDK 1.5 pour GNU/Linux sur mips (ou autre plateforme non x86/amd64). etc. Donc oui, ça n'est pas portable, du tout. N'en déplaise aux marketeux de chez Sun.

              Sur ce point on peut râler, car Sun ne permet même pas aux devs de LL de faire ces portages.

              Pour reprendre ta comparaison, on trouve des compilos C et C++ pour à peu pret toutes les plateformes existantes.
              Et des interpreteurs python aussi (qui, au passage, est aussi incorporé dans Ooo via PyUNO), lequel aurait été un choix moins problématique, s'ils cherchent des outils de dev rapide (et une gestion de la mémoire automatique).

              Pour le moment, gcj n'est pas lui même parfaitement "portable" (mais là, j'ai confiance, ça ne tardera pas).

              Pour revenir au sujet, le problème (outre toute considération technique) c'est qu'ils ont choisis la plateforme java la moins libre et la moins portable qu'ils pouvaient. Il n'est pas inutile que leurs utilsateurs leur donne un feedback pour faire savoir que ces détails ont leur importance.
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à -1.

        > c'est juste que moi je vois pas vraiment l'intérêt de faire chier le monde en liant OO.o avec Java aussi fortement.

        aussi fortement ?
        Où tu vois ça ?
        Ça ne conserne que des extensions. Libre a chaqu'un de les réécrire en autre chose que Java.
        Sun a décidé d'utiliser Java (techniquement, il semble qu'ils n'ont pas tord). En plus de proposer OOo sous GPL, on ne va pas leur imposer les méthodes de développement. Si le libre n'est pas satisfait, c'est à lui de prendre l'initiative (par exemple maintenir une version qui réimplémente les fonctionnalités actuellement en java).

        En te caricaturant, tu me fais passer à ceux qui gueulent car Linux n'est pas codé en C++. Fais le, c'est libre.
        • [^] # Re: Sun a toujours le mauvais rôle

          Posté par (page perso) . Évalué à 2.

          Fais le, c'est libre.
          Ben, ça c'est vite dit, tout dépend de ce qui va arriver aux brevets logiciels en Europe...
          C'est d'ailleur ca que je trouve bizzare, MS et Sun passe des accords de brevets pour ne pas s'attaquer mutuellement concernant leurs suites Office, donc je suppose qu'il doit y avoir matière à négociation (et donc brevets)... Mais d'un autre côté Sun a mis OOo sous GPL, dois-je supposer que les brevets en question ne concerne que StarOffice ? (les brevets étant incompatible avec la GPL, et Sun doit avoir pleinement connaissance de l'existance de brevets, chez Sun ou MS, puisqu'ils les "échangent")
          A vrai dire j'ai vraiment du mal à tout capter. En tout cas les brevets logiciel c'est vraiment dla merde :)
          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par . Évalué à 1.

            Puisque c'est Sun qui mets (peut-être) certains de ses brevets dans des programmes GPL, ses brevets ne sont plus valides (du moins pour les sources que Sun a mis sous GPL ; je ne sais pas si on peut extrapoler).
            Par contre, la jvm de Sun n'est pas libre. Donc s'il y a des brevets dedans, gcj ne peut pas les utiliser.
            OOo (GPL), ce n'est pas java. OOo utilise java. Donc OOo peut utiliser des brevets de Java. Le problème est là. Le jour venu, il y aura un fork (limité) pour ne pas utiliser les brevets de Java et pouvoir utiliser OOo avec gcj. Les sources java (fichiers .java) d'OpenOffice peuvent avoir des brevets. Le fait qu'ils soient sous GPL (sur décision de Sun) fait que le logiciel libre peut les utiliser (les fichiers .java d'OpenOffice).
            • [^] # Re: Sun a toujours le mauvais rôle

              Posté par (page perso) . Évalué à 2.

              Puisque c'est Sun qui mets (peut-être) certains de ses brevets dans des programmes GPL
              oué mais en supposant que ce soit des brevets MS ? (ce qui étant donné l'échange de brevets n'est pas impensable)
              Et même en supposant que ca soit Sun, pourquoi ce serait les brevets qui tout à coup se retrouverait invalidés ? Pourquoi ne serais-ce pas plutôt la licence qui serait invalidée ? Franchement la seule solution que je vois c'est que Sun utilise dans StarOffice des brevets MS (ce qui étant donné les nombreux points communs avec MS Office n'est pas impensable), et qu'ils préfèrent ne rien dire et ne pas changer la licence concernant OOo (d'ailleur que deviendrait la légalité des licences passées ?)

              Par contre, la jvm de Sun n'est pas libre. Donc s'il y a des brevets dedans, gcj ne peut pas les utiliser.
              T'as des infos sur les brevets en question ? (genre la liste)

              OOo (GPL), ce n'est pas java. OOo utilise java. Donc OOo peut utiliser des brevets de Java.
              Tiens content de voir qu'il n'y a bien aucun lien juridique entre l'utilisation et l'implémentation (sauf contrat explicite entre l'implémenteur et l'inventeur) ;)
              • [^] # Re: Sun a toujours le mauvais rôle

                Posté par . Évalué à 1.

                > oué mais en supposant que ce soit des brevets MS ? (ce qui étant donné l'échange de brevets n'est pas impensable)

                Alors Sun n'a plus le droit de diffuser OpenOffice (CF la licence GPL).

                > Et même en supposant que ca soit Sun, pourquoi ce serait les brevets qui tout à coup se retrouverait invalidés ?

                Il sont invalidé pour les sources que Sun a mis sous GPL. Je pensais avoir été clair. Relis.

                > Pourquoi ne serais-ce pas plutôt la licence qui serait invalidée ?

                Car Sun est le propriétaire des brevets *et* de la licence. C'est Sun via la licence qu'il a lui même choisi qui rend le code libre (du moins pour les éléments qu'il dispose ; c-à-d les brevets Sun qui seraient utilisé dans des sources GPL de Sun).

                > T'as des infos sur les brevets en question ? (genre la liste)

                Non. Je sais que c'est une préoccupation de gcj. RMS a aussi dit que certaines des dernières fonctionnalités de java ont des brevets. Que gcj n'implémentera pas ces brevets pour rester libre.

                > Tiens content de voir qu'il n'y a bien aucun lien juridique entre l'utilisation et l'implémentation

                Franchement, t'es lourd. Réfléchis un peu. Et j'aimerai que tu me dise où j'ai dit que l'utilisation et l'implémentation sont liés juridiquement ?
                Bonne chance. Je ne l'ai jamais dit car ça dépend des conditions de "vente" de l'utilisation (payant, sous condition, libre, libre seulement pour l'implémentation, libre seulement pour la lecture, etc) du brevet.
                J'ai dit, et je répète car t'es dure de la feuille :
                - Libre utilisation implique libre implémentation
                - Libre implémentation n'implique pas libre utilisation
                L'implémentation n'est qu'une des utilisations.
                • [^] # Re: Sun a toujours le mauvais rôle

                  Posté par (page perso) . Évalué à 1.

                  Il sont invalidé pour les sources que Sun a mis sous GPL. Je pensais avoir été clair. Relis.
                  Nan mais tu as été très clair j'ai bien compris, mais d'un point de vue juridique je ne vois pas comment une licence peut prendre le dessus sur un brevet logiciel : la licence s'a s'annule facilement, alors que bon un brevet ca reste un truc déposé par un organisme et tout... Enfin je dis ça mais tu as peut être raison. Reste qu'il manque à mon goût encore trop de jurisprudence en matière de licence, notamment GPL, parcque bon, si on se cantonne par exemple au droit pénal français, cette licence n'est même pas valable :-/

                  RMS a aussi dit que certaines des dernières fonctionnalités de java ont des brevets.
                  Oué bah oué mais c'est rigolo, c'est comme pour un autre projet (dont j'ai pas besoin de te citer le nom), on parle de brevets mais on n'en voit pas la couleur... Ils doivent bien être publiés quelque part non ? Je suppose que la team gcj y a accès pour savoir quelles techniques ils n'ont pas le droit d'utiliser non ?

                  Et j'aimerai que tu me dise où j'ai dit que l'utilisation et l'implémentation sont liés juridiquement ?
                  Nan mais c'était juste pour la vanne, restons-en là et parlons de Java :)
    • [^] # Re: Sun a toujours le mauvais rôle

      Posté par . Évalué à 10.

      une interview d'un des developpeurs d'OpenOffice.org a cité une raison toute bête et visiblement pas évoquée ici-bas :

      http://software.newsforge.com/software/05/03/22/204244.shtml?tid=93(...)

      ils sont parfaitement au courant des caractéristiques techniques et des avantages et contraintes relatives à C++ et Java, et du rôle complexe que Sun tient dans ce petit monde : mécène, bienfaiteur, dictateur bienveillant ou pas, croquemitaine.

      mais pour certaines fonctionnalités, il s'est trouvé des développeurs Java pour se mettre au boulot, et pas de développeurs C++. tout simplement :

      "And sometimes, Schönheit adds, "this simply means that there is a Java developer who can spend time on a project, and no C++ developer who can."

      alors au lieu de râler aujourd'hui comme de bêtes utilisateurs finaux et autres consommateurs de logos & sonneries, il fallait répondre à l'appel quand ils ont eu besoin de vous. le Libre, c'est fait pour ça aussi.


      NB : cet argument du manque de bras pourrait difficilement justifier l'ajout de nouveaux langages et dépendences sans vrais rapports avec la choucroute au projet existant, mais il y avait déjà des sales gros bouts en Java dedans. par ailleurs, j'ai une dent féroce contre les nombreuses faiblesses de Java, donc on pourra difficilement m'accuser de bienveillance à son égard. mais l'argument du monsieur se tient : à un moment il a fallu coder des trucs, et visiblement seul un développeur Java a bien voulu s'en occuper.
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par (page perso) . Évalué à 7.

        >> mais pour certaines fonctionnalités, il s'est trouvé des développeurs Java pour se mettre au boulot, et pas de développeurs C++. tout simplement

        A première vue cet argument semble solide.
        Mais tout à coup on se demande en quoi cela s'applique à une réécriture complète des wizards de Writer ?

        Autant pour developper de nouvelles fonctions on fait avec les compétences du mec qui est disponible mais la ce n'est pas du tout le cas : on réécrit un truc qui existe déja et qui ne pose pas de problèmes en en faisant un problème potentiel.

        Pareil pour Base : SQlite existait déja et il sont allé chercher, comme par hasard, une base en Java.

        Donc pour moi l'argumentation du simple hasard (oh y'avait juste un seul volontaire et il connaissait que Java) est eminement suspecte.
        • [^] # Re: Sun a toujours le mauvais rôle

          Posté par (page perso) . Évalué à 4.

          Donc pour moi l'argumentation du simple hasard (oh y'avait juste un seul volontaire et il connaissait que Java) est eminement suspecte.

          C'est pas compliqué à comprendre. Sun désire diffuser toujours plus leur technologie java. OOo est un superbe moyen de l'imposer petit à petit ...
          Et à leur place je ferais pareil, mais à la place du Libre (en supposant qu'il ait une conscience unique) je me concentrerais sur abiword...
          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par (page perso) . Évalué à 7.

            j'aimerais vraiment qu'abiword/gnumeric annoncent leur switch vers le format OpenDocument (Oasis) comme l'a déja annoncé Koffice.
            Si toutes les suites bureautiques libres soutiennent OpenDocument alors le choix des utilisateurs sera vraiment libre (en fonction des qualités propres des softs).
    • [^] # Re: Sun a toujours le mauvais rôle

      Posté par . Évalué à 3.

      L'important c'est peut être de faire assez de bruit pour que l'equipe d'Ooo developpe en visant gij ou kaffe plutôt que les environements Sun.

      Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre : il ne s'agit pas de webdesigners du dimanche (à qui on peut passer l'utilisation de features "ie-only"), mais de developpeurs expérimentés. Et dont je croyai qu'ils connaissaient les préocupations et problèmes des utilisateurs de LL.

      Si nous passions ça sous licence, il est à peut près certain qu'aucun effort n'aurait été fait pour conserver la compatibilité gcj, si durement acquise, dans les versions ultérieures.

      Et au passage le fait que ça marchouille avec le gcj de FC4 (et combien de patches ?) n'est pas satisfaisant: ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.

      En somme, la réaction des utilisateurs de LL est cohérente avec ce que recommande Stalman:
      http://www.gnu.org/philosophy/java-trap.html(...)
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à 4.

        > Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre

        J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici) :
        http://www.spindazzle.org/green/index.php?p=43(...)

        Je l'ai ici, et ça marche !

        > Et au passage le fait que ça marchouille avec le gcj de FC4

        Ça ne marchouille pas, ça marche !
        Va sur les mailing Fedora pour connaitre les feedback ou vas faire un tour sur le bugzilla de Red Hat pour avoir un état des lieux :
        http://bugzilla.redhat.com/(...)

        > et combien de patches ?

        Un patch ridicule.
        [admin@one SOURCES]$ cat workspace-gcj4.patch | diffstat
        bin/deliver.pl | 0
        config_office/configure.in | 21 +++++++++++++++++++++
        config_office/set_soenv.in | 8 +++++++-
        inc/settings.mk | 0
        solenv/bin/deliver.pl | 22 ++++++++++++++++++++++
        solenv/inc/settings.mk | 5 ++---
        6 files changed, 52 insertions(+), 4 deletions(-)

        > ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.

        Et alors ? OOo 2.0, nécessite OOo 2.0 en version beta actuellement.
        gcj 4.0 est utilisé depuis FC3. gcc 4.0 est en "open for regression fixes only".

        > En somme, la réaction des utilisateurs de LL est cohérente avec ce que recommande Stalman:

        La réaction des utilisateurs du LL serait de "sauter" sur gcj 4.0.

        > http://www.gnu.org/philosophy/java-trap.html(...)

        On peut se demander si tu as lu le lien :
        The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system.

        gcj c'est bon, mangez en (au lieu de faire des critiques à deux balles).

        PS : Avant de poster des commentaires, lisez les commentaires déjà postés.
        • [^] # Re: Sun a toujours le mauvais rôle

          Posté par . Évalué à 2.

          >> Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre
          >
          > J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici)


          Ça marche _après_ patchage d'Ooo et ajustements de classpath etc. Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.

          S'ils continuent sur cette voie, il faura repatcher tout son système à chaque mise à jour d'Ooo ? Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ? Très forts les prosélytes de java et fedora.


          > Un patch ridicule.

          Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner. Y compris les modifications de gcj et de classpath.


          > On peut se demander si tu as lu le lien :
          > "The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system"


          Citation tronquée et détournée. L'ensemble du document dit qu'il faut faire comprendre aux devs java qu'ils doivent _developper_ avec une implementation libre de java sur le systeme. La paragraphe que tu cite est:

          "The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately."

          Ce qui n'a pas été fait.


          > Avant de poster des commentaires, lisez les commentaires déjà postés.

          Le fait que je n'ai pas le même avis sur toi ne doit pas te faire déduire que je n'ai pas lu les commentaires ...

          En lisant le reste de mon commentaire, tu a très bien compris que j'avait lu le tien.
          • [^] # Re: Sun a toujours le mauvais rôle

            Posté par . Évalué à 4.

            Faut calmer ton FUD. Quand on ne sait pas, on n'invente pas.

            > Ça marche _après_ patchage d'Ooo

            Linux est patché, la libc est patché, etc... Ton argument c'est 0, surtout que OOo 2.0 est en phase beta/rc.

            > ajustements de classpath etc.

            gcc :
            [admin@one SOURCES]$ cat gcc4-java-nomulti.patch | diffstat
            configure | 3 +++
            configure.ac | 4 ++++
            2 files changed, 7 insertions(+)

            Fichtre, aucun ajoutement de classpath spécifique à OOo.

            > Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.

            Et alors ?
            Sun s'occupe de leur java, le libre s'occupe de son java. Le libre peut bien ce sortir les doigts du cul.

            > Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ?

            Et pourquoi tu n'installes pas gcc3 en parallèle avec gcj 4.0 ? C'est fait les doigts dans le nez avec FC3. Possible que OOo 2.0 soit disponible pour FC3 car le fichier spec intègre gcc4 en compilateur par défaut (FC4) ou gcc3 en compilateur par défaut (FC3).
            http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/openoffic(...)

            > Très forts les prosélytes de java et fedora.

            M'enfin, tu me fais rire. On sait déjà comment ça va se terminer. T'as un troupeau d'anti-RH qui va gueuler (c'est leur façon de promouvoir leur distrib), puis 3 semaines après ça va être dans leur distribution et il vont fermer leur gueule. Ça se passe toujours comme ça.

            Si tu ne veux pas utiliser gcj qui est libre, t'es libre. C'est ton choix. Mais inventes pas des trucs à la con.

            > Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner.

            Quelles modifications ? Les modifications pour améliorer gcj ? Oui, il y en a des tonnes et c'est tant mieux. Tu veux quoi ? Que gcj reste figé et qu'on soit obligé d'utiliser un jvm proprio ?
            Pas moi.

            > Ce qui n'a pas été fait.

            Ce qui a été fait par Red Hat. Donc l'OOo de Sun, modulo un patch rididule de 50 lignes respecte à la lettre la requête de RMS.

            Je ne suis pas un dingue de Sun (parqu'ils sont pro-brevets). Mais j'en ai archi-marre des gens qui gueulent sur Sun pour des problèmes qui ne sont pas lié à Sun. Si gcj sucks, c'est un libre d'améliorer gcj. Si Sun veut y participer, tant mieux.
            Les gens sont complètement incohérent. Si une boîte participe trop, ils gueulent. Si elle participe peu, ils gueulent encore. Faudrait savoir ce que vous voulez.

            Deuxième truc qui me gave c'est le "ouais mais c'est patché". Qu'es-ce que c'est que cette argument à la con ?
            Quand Ubuntu patch, qui se plaind ? Personne et c'est très bien.
            Quand un noyau sort, des gens parlent du patch mm, du patch de mise à jour IDE ou USB, des patchs Red Hat ou Mandrake, du patch xen, du patch pour avoir reiser 4, etc...
            Personne n'y trouve à redire car c'est ça le logiciel libre. Laisser à chaqu'un la liberté de bosser.
            La communauté qui veut du java libre, bosse sur gcj. Parfois ça peut-être fait en upstream (c'est le cas pour 99,9% des améliorations de gcj), parfois ce n'est pas possible ou approprié.
            • [^] # Re: Sun a toujours le mauvais rôle

              Posté par . Évalué à -3.

              > Fichtre, aucun ajoutement de classpath spécifique à OOo.

              En upstream. Tu es débile ou tu fait semblant ?
              • [^] # Re: Sun a toujours le mauvais rôle

                Posté par . Évalué à 1.

                > En upstream. Tu es débile ou tu fait semblant ?

                Donc, selon toi, il ne faut pas améliorer gcj en upstream ni avec des patchs.
                Ben on n'est pas sorti de l'auberge.
                Tu connais des modifications de gcj/classpath qui sont spécifiquement faites pour supporter OOo 2.0 ?

                Je ne suis pas débile et toi t'es très con. Tu veux que gcj n'évolue pas.
    • [^] # Re: Sun a toujours le mauvais rôle

      Posté par . Évalué à 2.

      Ainsi Jonathan Schwartz (le pres' de Sun) ne pourra plus prétendre que la communauté du LL est grande amie de Java, comme il le faisait souvent.

      De mémoire, on n'a jamais vu une telle réaction pour le choix d'un autre langage dans un LL.

      Maintenant les choses sont plus claires.
      • [^] # Re: Sun a toujours le mauvais rôle

        Posté par . Évalué à 2.

        La communaité libre n'apprécie pas (à juste titre) la license proposée par Sun pour son environnement Java (comme elle n'apprécie pas la license DB2 d'IBM, de Photoshop, de Windows, etc...). Cela ne signifie pas qu'elle n'apprécie pas les mérites technologique du langage. Loin s'en faut. Regarde le nombre de projets libres écrits en Java, c'est assez impressionant.

        > De mémoire, on n'a jamais vu une telle réaction
        > pour le choix d'un autre langage dans un LL.

        J'aurais bien été tenté par ksh88...
  • # Commentaire supprimé

    Posté par . Évalué à -4.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: arreter de contribuer et d'envoyer de rapport de bug pour OOo

      Posté par . Évalué à 2.

      introduire de force java dans des composants essentielles c'est vicieux et ca fonctionne bien

      Tu n'as pas eu le temps de lire la news et les commentaires ?
      Néanmoins ce ne sont que des fonctionnalités annexes et quelque peu périphériques
      et
      Actuellement ça marche (j'ignore si tout est fonctionnel) ; xsl ; odbc.
      C'est configuré avec :%configure --with-java=gij --

      http://about.me/straumat

    • [^] # Re: arreter de contribuer et d'envoyer de rapport de bug pour OOo

      Posté par . Évalué à 2.

      > introduire de force java

      C'est principalement Sun qui bosse sur OOo. Donc, il font ce qu'ils veulent. Ce qui n'empêche pas qu'on peut ne pas aprécier certaines décisions.

      > dans des composants essentielles

      Lesquels puisque que OOo peut encore marcher sans java ?
  • # Le problème: c'est Java ou Sun?

    Posté par . Évalué à 8.

    Ce qui m'interpelle le plus est: pourquoi Java est il toujours un fardeau après de nombreuse années.

    Sur le papier l'idée est séduisante. Langage OO relativement propre exécuté par une machine virtuelle. Perl, Python, Ruby ou Ocaml n'ont pas les problèmes de Java tel que: API mammouthesque, lourdeur/lenteur, licence problématique. Sun et sa stratégie ne serait il pas le réel problème de Java? Et peut être le futur de Open Office?

    J'ai programmé une seule fois en Java avec l'api Swing sur un athlon 1.3Ghz. La seule opinion qu'il m'en reste, c'est qu'il suffisait de bouger la souris rapidement pour se faire une idée des performances lamentables de Java Swing ... Depuis, Java me donne des frissons. Open Office 1 est déjà un mammouth, qu'est que ça va être avec Java ...
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par . Évalué à 2.

      J'oubliais. J'ai eu la joie de découvrir Maple 9.2 Linux avec la nouvelle GUI Javaiser: formidable!, avant c'était du Motif hideux, maintenant ça explose (100ène process, 100 % mem, 100% cpu) un P4 à 2.4Ghz. Merçi Maple pour ce choix judicieux! Heureusement qu'ils utilisent GNU MP pour compenser ...
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par . Évalué à 3.

      Et c'était quand ? Parce que tu devrais essayer certaines applications modernes avec une JVM moderne. Evidemment Java ne propose pas des performances exceptionnelles dans toutes les situations mais ce n'est pas le problème majeur. Le gros gros gros problème de Swing est qu'il est terriblement FACILE de coder quelque chose de lent. En revanche, en connaissant la manière dont Swing est architecturé (beaucoup de lectures et un peu d'expérience) on peut obtenir des résultats impressionnants. Et il reste toujours l'option SWT.

      Java sur le desktop a encore du chemin à faire mais c'est viable.
      • [^] # Re: Le problème: c'est Java ou Sun?

        Posté par . Évalué à 1.

        Maintenant que XUL commence à être assez mature, je ne vois plus trop l'intêret de Swing ...
        • [^] # Re: Le problème: c'est Java ou Sun?

          Posté par . Évalué à 1.

          As-tu déjà utilisé Swing et XUL pour développer ? Si oui, tu saurais pourquoi Swing a un intérêt ;-) Et puis il existe déjà des "interpréteurs" XUL pour Java/Swing :p
          • [^] # Re: Le problème: c'est Java ou Sun?

            Posté par . Évalué à 1.

            Oui, j'ai déjà développé avec les 2, et je maintient ce que je dis. Swing n'est absolument pas une "technologie" d'avenir même si c'est plus puissant que XUL pour l'instant (quoique avec XBL, les templates et cie, on peut quand même faires des trucs sympas).

            Pour du développement multi-plateforme, moi je trouve que la plateforme Mozilla 2.0 + Python par exemple, ça promet bien plus que Swing.
          • [^] # Re: Le problème: c'est Java ou Sun?

            Posté par . Évalué à 2.

            Ouaip j'ai essayé de coder en XUL/RDF/... Après quelques dizaines d'heures de code (!) je suis arrivé à un tout petit plugin. Du coup je suis retourné vers mon petit V4ALL sous Eclipse.

            Ok, Swing c'est lent (et encore... ça dépend comme on code), mais au moins c'est rapide à coder. C'est dommage mais c'est la vie...
      • [^] # Re: Le problème: c'est Java ou Sun?

        Posté par . Évalué à 3.

        En même temps SWT sous Linux c'est par super rapide, alors que Swing a fait des progrès impressionnants à ce niveau et est suffisamment réactif sous Linux comme sous Windows (en tout cas avec la JVM 1.5 de SUN).

        Netbeans (swing) est par exemple bien plus réactif que Eclipse (SWT/GTK) sous Linux.

        De plus il semble que le support de Swing avec gcj/classpath avance assez rapidement grâce à RedHat. Le rendu utilisant GTK...
        Il est d'ailleur possible d'utiliser directement GTK.
        Du coup l'intérêt de SWT me semble de plus en plus limité. C'est une stratégie bizarre d'IBM qui semble pousser SWT alors qu'il a participé à l'élaboration de Swing.

        Pour revenir à la discussion initiale, vu que bientôt on aura une implémentation correcte et libre de Java, je ne vois vraiment pas pourquoi on fait tout un fromage autour de l'utilisation de Java avec OpenOffice. Java permet un developpement plus rapide qu'en C et C++ sans sacrifier les performances (par contre la mémoire...). Si les développeurs considèrent que c'est un bon choix technique, je ne vois pas où est le problème.

        Par contre les perfs de Gcj face aux JVM récentes de SUN ou d'IBM c'est pas encore ça... [! troll detected...!]
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par (page perso) . Évalué à 3.

      On peut tout de même se rassurer en constatant que OOo n'utilise pas Swing.

      Moi y'a un seul truc qui me dérange : ok on aura tôt ou tard un OOo utilisable sous Linux avec gcj, mais sous quid sous Windows ? Y-a-t-il d'autres JVM libres qui seront supportés sous Windows ?
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par . Évalué à 2.

      C lourd ca.... essaye eclipse et arrete de dire ensuite que java est lent...
      quand à l'api, elle est énorme mais permet de tout faire

      http://about.me/straumat

      • [^] # Re: Le problème: c'est Java ou Sun?

        Posté par . Évalué à 3.

        Bah j'ai essayé Eclipse, et je trouve toujours que Java est lent... Ce que tu veux probablement dire, c'est que Java n'est pas trop lent pour que sa lenteur justifie le fait de ne pas l'utiliser... je suis plutôt d'accord.
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par . Évalué à 6.

      J'ai programmé une seule fois en Java avec l'api Swing


      Et donc tu te sens autorisé à faire des commentaires à l'emporte pièce sur ce langage, alors que de ton propre aveu tu ne le connais pas ou presque. Bien bien...
      • [^] # Re: Le problème: c'est Java ou Sun?

        Posté par . Évalué à 1.

        Certes. Mais,

        - Il y a 2 ans, si tu redimensionais très rapidement un hello word ou à peine plus compliquer, ça suivait pas.

        - Et j'ai vue très récemment un crash magnifique de Maple 9.2. Vue le nombre de processus java, on dirait qu'il créé un thread par pixel!

        J'ai rien contre Java. Je critique juste le fait de vendre des logiciels inutilisables.
        • [^] # Re: Le problème: c'est Java ou Sun?

          Posté par . Évalué à 0.

          tututut....

          Quand le physicien des particules se fait choper par un informaticien sur une question d'informatique, le physicien des particules se tait humblement :P

          Ou sinon, moi non plus j'ai rien contre Java, d'ailleurs je suis sur que si ROOT avait ete ecrit en Java, ce serait moins de la merde (et je pese mes mots) !

          PS: DEA powa ;)
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par (page perso) . Évalué à 3.

      API mammouthesque

      L'api de Perl est mammouthesque, comme tu dis, par qu'on peut tout faire avec Perl. C'est la même chose en Java. Je ne connais pas assez Python et Ruby pour comparer, mais je doute qu'on puisse faire autant de chose qu'en Java si l'API est significativement plus petite. Par contre, je suis certain qu'on peut faire moins de chose en OCaml. Attention, qu'on se comprenne bien, je ne parle pas ici de théorie, je parle d'API disponibles pour faire des choses évoluées (parler à un serveur SMTP, parser un mail, parser du XML, parler web services, etc.) sans avoir à se palucher tout à la main.

      lourdeur/lenteur

      Lourdeur, soit, Java demande beaucoup de mémoire. Lenteur, n'importe quoi. Documente toi, utilise une JVM moderne et une mémoire correctement dimensionnée, et tu verras que Java n'est pas lent.

      licence problématique

      Beaucoup plus que Perl/Python/etc., c'est vrai. Mais est-ce que tu sais de quoi tu parles ou est-ce que tu ne fais que répéter les trolls standards ?
    • [^] # Re: Le problème: c'est Java ou Sun?

      Posté par . Évalué à 5.

      J'ai programmé une seule fois en Java avec l'api Swing sur un athlon 1.3Ghz.

      oserais-je émettre l'hypothèse que tu peux difficilement prétendre avoir appris à programmer correctement en Java et à utiliser correctement les JFC (autre nom de Swing) en "une seule fois" ?
  • # O1.net : Java s'ouvre encore plus à l'open source

    Posté par . Évalué à 0.

    Une petite news bien écrite, de O1.net et relayée par Yahoo!, qui tombe à pic pour nourrir le troll la réflexion :
    http://fr.news.yahoo.com/050329/44/4c558.html(...)
    • [^] # Re: O1.net : Java s'ouvre encore plus à l'open source

      Posté par (page perso) . Évalué à 0.

      Un des arguments de Sun pour ne pas ouvrir Java était un possible fork. Vu la taille du projet peut-on imaginer un fork ?
      • [^] # Re: O1.net : Java s'ouvre encore plus à l'open source

        Posté par . Évalué à 3.

        Un des arguments de Sun pour ne pas ouvrir Java était un possible fork.


        C'est très étonnant car justement c'est souvent le contraire qui se produit : si un éditeur (propriétaire) fait un super produit, il finit souvent par copié par des développeurs du Libre...

        Lire à ce sujet : Fear For Forking (la peur du fork) http://linuxmafia.com/faq/Licensing_and_Law/forking.html(...)
        • [^] # Re: O1.net : Java s'ouvre encore plus à l?open source

          Posté par (page perso) . Évalué à 7.

          Fear For Forking (la peur du fork) http://linuxmafia.com/faq/Licensing_and_Law/forking.html(...)


          Excellent document écrit dans un anglais facile à lire.
          Il serait urgent de le faire lire aux dirigeants de SUN (même par la contrainte;-).

          Je pense que si SUN avait mis Solaris sous GPL il y a 10 ans, il aurait pu le sauver. Maintenant c'est trop tard, leur demi ouverture du code n'intéresse plus grand monde. J'ai bien l'impression qu'ils vont réaliser la même erreur avec java.

          Les dirigeants des grandes sociétés n'ont pas encore compris que le monde était en train de changer profondément et que les raisonnements appris dans leurs manuels étaient obsolètes.
          Il semble que seul IBM l'ait compris. Leur arrogance du début des années 1990 a failli leur faire mettre la clef sous la porte tellement ils étaient sûrs de leur business model. Ils ont aussi perdu sur OS/2 qui aurait pu être un sérieux concurent de Windows car il était bien meilleur. Pour en avoir baissé le prix tardivement (Warp fut un échec), et faute de l'avoir ouvert et ouvert à temps, il est maintenant moribond.

          Allez Mr Sun, n'ayez pas peur, mettez le code java sous GPL. Il est peut être encore temps, mais chaque jour d'attente vous rapproche inexorablement du jour où vous direz "too late..." et il sera bien entendu trop tard.
    • [^] # Re: O1.net : Java s'ouvre encore plus à l'open source

      Posté par (page perso) . Évalué à 2.

    • [^] # Re: O1.net : Java s'ouvre encore plus à l'open source

      Posté par . Évalué à 1.

      Comme nid à troll on ne fait pas mieux. Et en plus c'est bourré de conneries ( Blackdown n'est pas libre mais "appartient" de fait à Sun, les projets Java libres sont nettement antérieurs à Mono, plus la cote : sur monster.fr 530 offres d'emplois en Java pour 92 en C#, bref que du n'importe quoi!). C'est tjs navrant de voir que moteurs à priori sérieux reprennent ce genre de news.
  • # Inquetudes ... Peut etre que ...

    Posté par . Évalué à 5.

    Bonjour,


    Peut etre que le plus inquetant dans tout cela ca n'est pas trop le fait que certains modules OpenOffice soient en Java , mais le fait que cela va peut etre conduire certains contributeurs à arreter leur collaboration.

    Ce qui est inquetant , à mon sens, c'est plus la dillution de l'effort. Ok ca ne va plus comme on l'entend alors on bouge sur un autre pojet ? . Et pourquoi pas un autre projet parallele ? . C est un cas de figure qui se repete de plus en plus.
    Je pense que si on veut avoir des produits capables de rivaliser (et aussi les depasser) avec des applications commerciales la solution est plus la cohesion autour d'un ou deux grands projets afin de pouvoir proposer une reelle alternative (cf dev Mozilla / Firefox).

    Bien sur il ne s'agit la que d'un point de vue parmis tant d autres. ;) .

    Merci de me lire.

    Slts
    Guillaume.
    • [^] # Re: Inquetudes ... Peut etre que ...

      Posté par . Évalué à 4.

      On voit ici une grande différence entre le mouvement du libre et celui du propriétaire : les développeurs de logiciels libres ne sont pas pieds et poings liés à leurs projets, ce serait plutôt l'inverse, et encore même pas.

      On ne peut pas faire coder des gens qui ne veulent pas coder, donc il faut faire avec leurs compétences ET leur caractère. Certains vont s'en plaindre, mais ce sont généralement pas ceux qui sont les plus grands contributeurs du Libre, ni les plus grands bénévoles de tous les temps...

      De plus, ce qu'il faut voir pour de grands projets comme OOo, c'est que de nombreux contributeurs contribuent en étant employés dans des entreprises. Si ces entreprises ne voient pas d'un bon oeil l'omniprésence de SUN (via Java), elles vont peut-être aussi accélérer ce mouvement de rejet.
    • [^] # Re: Inquetudes ... Peut etre que ...

      Posté par . Évalué à 0.

      Ou l'inverse. Si Java apparaît vraiment dans OOo ça pourrait m'intéresser de contribuer. J'avais tenté le coup mais quand j'ai vu la taille et la complexité du truc, j'ai laissé tomber. Mes (maigres) connaissances du C++ ne m'aidaient vraiment pas à m'intégrer au projet.
  • # KDE et QT

    Posté par (page perso) . Évalué à 10.

    Je ne voudrais pas passer pour un vieillard radoteur mais ça me rappelle foutrement le débat sur l'indépendance de KDE par rapport à QT.

    L'expérience à montré alors que intransigeance était la meilleure politique : l'industriel assoupli sa politique de peur de se voir exclure complètement et dépassé par un projet concurent.
  • # java suçe.

    Posté par . Évalué à -10.

    java sa pue, sai pas libre, la portabilité est un concept à la con de vendeurs de lessive, SUN=ARIEL/OMO Micro
    Il n'y aura jamais de JVM libre performante, baser un projet de grande envergure libre là dessus est une connerie en barre.
    • [^] # Re: java suçe.

      Posté par . Évalué à -1.

      Je me suis permis d'inutiliser d'eclipser ton commentaire. Tu ne m'en veux pas j'espère.
      • [^] # Re: java suçe.

        Posté par . Évalué à -7.

        pas le moins du monde j'ai fait pareil
        • [^] # Re: java suçe.

          Posté par . Évalué à -1.

          Sauf qu'on est plus nombreux a s'etre rendu compte de la connerie de ton commentaire, c'était trop ridicule!

          http://about.me/straumat

    • [^] # Re: java suçe.

      Posté par (page perso) . Évalué à 0.

      faut que eclipse, netbeans, jbuilder, limewire, ThinkFree Office cesse d'être...


      j'espère que tu utilises un bios libre pour raconter autant de connerie

      www.solutions-norenda.com

  • # Je me disais aussi...

    Posté par . Évalué à 2.

    J'avais tellement espéré une amélioration des performances d'OpenOffice dans la version 2 que le choc a été rude avec ces versions Beta.
    Je comprend mieux maintenant.
    Plus il y a de Java, plus c'est lourd à charger...
    Je trouve Java performant essenciellement sur les serveurs, les applications clientes sont peu populaires, peut être à cause du temps de chargement du JRE.
    Les performances du 1.5 sont-elle vraiment meilleures ? de beaucoup ? On a que la 1.4.2 nous en Prod.

    L'idéal serait un XULOffice.
    Un programme qui manipule du XML (qui est une technologie Web) serait facile et rapide à développer avec une technologie Web.
    En plus, on pourrait l'utiliser à distance dans Firefox à terme peut être.

    Une fois XULRunner terminé, l'occupation mémoire sera optimisée et on disposera d'une plateforme de développement qui méritera largement d'avoir sa suite Office..
    • [^] # Re: Je me disais aussi...

      Posté par . Évalué à 3.

      J'utilise Java depuis longtemps (doux euphémisme) et je dois avouer que J2SE 5.0 m'a véritablement surpris au niveau des performances de Swing et des temps de chargement. Pour Swing tu peux encore améliorer les choses en activant le pipeline de rendu OpenGL pour Java2D. Il y a un petit swtich dont le nom m'échappe pour cela.
    • [^] # Re: Je me disais aussi...

      Posté par . Évalué à 1.

      Ton XUL office, comme tu dis, est en travaux depuis plus d'un an et devrais sortir courant Avril si mes souvenirs sont bons.
      • [^] # Re: Je me disais aussi...

        Posté par . Évalué à 2.

        Ton XUL office, comme tu dis, est en travaux depuis plus d'un an et devrais sortir courant Avril si mes souvenirs sont bons.


        Un nom ? Une URL ?

        J'ai cherché un peu, je n'ai trouvé que mozOffice : http://mozoffice.sourceforge.net(...)
        Mais le projet semble mort (dernière nouvelle : 06/11/2002)
      • [^] # Re: Je me disais aussi...

        Posté par . Évalué à 0.

        Romain a raison, ton post ne vaut pas grand chose si tu ne nous en dit pas plus.
        Par contre, une URL et je me prosterne... :)
    • [^] # Re: Je me disais aussi...

      Posté par . Évalué à 1.

      > J'avais tellement espéré une amélioration des performances d'OpenOffice dans la version 2 que le choc a été rude avec ces versions Beta.

      T'es de mauvaise fois ou alors tu as déjà une JRE sur ta bécane. Actuellement il n'y a que Fedora qui a OOo/gcj (c'est en beta/test).
      Pour avoir testé sous Fedora, OOo 2.0 est plus rapide que OOo 1.1.
      • [^] # Re: Je me disais aussi...

        Posté par (page perso) . Évalué à 2.

        pas besoin d'utiliser Fedora pour ce rendre compte que OOo2 est vraiment beaucoup plus rapide que OOo 1.x

        c'est le jours ou la nuit

        www.solutions-norenda.com

        • [^] # Re: Je me disais aussi...

          Posté par . Évalué à 2.

          "c'est le jours ou la nuit"
          Oui mais on est passé d'un programme très lent à charger à un programme lent à charger.

          Pour moi, ca devrait s'appeler 1.2 et pas 2.0
          à moins que des fonctionnalités révolutionnaires n'aient été ajoutées (auquel cas je ne m'en servirai sans doute jamais).

          Le probleme semble être le meme que pour Netscape : Un gros code bien inextriquable. Et comment Mozilla s'est sorti de ce pétrain ? En séparant UI, Comportement et traitement. Voire meme en séparant les fonctionnalités (mail, surf...). Je pense pas que OpenOffice opte pour cette voix...
          • [^] # Re: Je me disais aussi...

            Posté par (page perso) . Évalué à -1.

            en plus d'être de mauvaise foi, tu nages dans l'absurdité

            faudrait peut-être que tu arrêtes ton quake 3 en essayant OOo 2...

            n'importe quel review le confirme, OOo 2 s'est grandement améliorer en temps de chargement, on est tout près de ce ms office arrive à obtenir...

            si on veut démarrer plus rapidement faut lancer démarrage rapide

            www.solutions-norenda.com

            • [^] # Re: Je me disais aussi...

              Posté par . Évalué à 2.

              Soyons clair, ok :
              J'ai un PC sous Windows (evidement, pour comparer...).
              Pas de logiciel de lancé.
              Pas de "démarrage rapide" (si tous les logiciels en avaient un ce serait la misèrre)
              Je lance Office 2003, je ferme
              Je lance OpenOffice 2
              Je commente même pas la comparaison, je vous laisse juger.

              Je vois pas la mauvaise foi. Pour moi, c'est être réaliste. Mon but est que mes amis utilisent OOo à la place d'Office en préparation d'une migration Linux. Tout se passe bien pour Firefox, Thunderbird, Psi (quoique), mais ca coince sur OOo : ils me disent "trop lent".

              Je sens que quand QTWin permettra le port de KDE sous Windows, je vais leur faire gouter du KOffice qui me semble quand meme plus rapide.
    • [^] # Re: Je me disais aussi...

      Posté par (page perso) . Évalué à 1.


      Les performances du 1.5 sont-elle vraiment meilleures ? de beaucoup ? On a que la 1.4.2 nous en Prod.



      pour des performances quelques bench

      http://www.laboiteaprog.com/tutoriel72-5(...)

      après faut voir ce que ça donne pour un programme complet...

      www.solutions-norenda.com

      • [^] # Re: Je me disais aussi...

        Posté par . Évalué à 2.

        He bin c'est pas très encourageant pour gcj et redhat çà :/, ca aurait été marrant de comparer aussi avec son principal concurrent libre lui aussi , mono.
      • [^] # Re: Je me disais aussi...

        Posté par . Évalué à 2.

        Juste comme ca, je viens de regarder en diagonal le code de fibo et ackermann, car les resultats me paraissaient etrange. En faite ton code ne permet pas du tout, en C++, au compilo d'optimiser la tail recursivite. Il vaut mieux ecrire fibo comme ca a priori :


        static const unsigned long optfib(const unsigned long n, const unsigned long sum) {
        if (n < 2)
        return 1 + sum;
        else
        return optfib(n-2, optfib(n-1, sum));
        }

        static inline const unsigned long fib (const unsigned long n)
        {
        return optfib (n, 0);
        }


        (Un "objdump -d" sur le binaire te montrera qu'il n'y a plus que un seul vrai appel de fonction, les autres ayant ete remplace par des sauts). Pour Ackermann, ce serait plutot comme ca :

        const int Ack(const int M, const int N)
        {
        if (!M)
        return N + 1;
        else
        if (!N)
        return Ack (M - 1, 1);
        else
        return Ack (M - 1, Ack (M, N - 1));
        }


        Dans cette version de Ack, il ne restera aussi que un seul vrai call.

        Sinon je ne connais pas le Java suffisament bien, mais j'avais cru comprendre qu'il y avait un garbage collector, donc tester l'allocation dans objinst ne me parait pas tres convaincant, car pour le C++, c'est un delete pour chaque new, tandis que pour Java, il va pouvoir mutualiser ce genre d'operation. Dans un gros programme en C ou C++ on gagne toujours enormement a gerer correctement sa memoire (sans directement utiliser malloc/free ou new/delete). Donc ce critere me parait au mieux biaise.

        Enfin pour wc, le dico doit etre un peu petit parce que les temps sont tous tres proches et la moindre variation dans la charge de la machine pourrait avoir un effet sur les resultats.
        • [^] # Re: Je me disais aussi...

          Posté par (page perso) . Évalué à 1.

          je mettrais cette fin de semaine les résultats des tests avec ton code

          pour objinst, créer et détruire un objet à un coût que ça soit pour java ou c++... ta delete pour c++ et de l'autre côté tu auras rapidement le garbage collector

          pour wc, tel que dit, le fichier a quelques millions de lignes

          il y a t'il quelqu'un qui est capable d'optimiser le code java?

          www.solutions-norenda.com

      • [^] # Repompage malhonnête

        Posté par . Évalué à 1.

        C'est quand même malhonnête de n'avoir pas mentionné que ton benchmark n'est qu'un repompage sélectif du Computer Language Shootout disponible ici, et auquel tout le monde peut contribuer :
        http://shootout.alioth.debian.org/(...)

        J'encourage tout le monde à envoyer ses améliorations directement au Shootout sus-cité, ce sera plus utile.
        • [^] # Re: Repompage malhonnête

          Posté par (page perso) . Évalué à 0.

          Malhonnête?

          apprend à lire plutôt

          c'est clairement indiqué:

          Les tests réalisés ont été fait à partir des sources dipsonibles à JavaBench.

          www.solutions-norenda.com

          • [^] # Re: Repompage malhonnête

            Posté par . Évalué à 2.

            Ok, je n'avais pas vu le lien vers "Javabench"... Ç'aurait été plus évident si les liens n'étaient pas affichés de la même couleur que le reste du texte !

            Ma remarque reste quand même valable dans la mesure où tu maintiens ton propre sous-ensemble (probablement pas à jour) du Shootout alors que tu pourrais très bien apporter à celui-ci tes améliorations, afin que l'effort communautaire ne se disperse pas.
            • [^] # Re: Repompage malhonnête

              Posté par (page perso) . Évalué à -1.

              Ma remarque reste quand même valable dans la mesure où tu maintiens ton propre sous-ensemble (probablement pas à jour) du Shootout alors que tu pourrais très bien apporter à celui-ci tes améliorations, afin que l'effort communautaire ne se disperse pas.


              pas vraiment le temps et surtout bon commencer à perdre du temps pour savoir celui qui a la plus grosse...

              ces bench ne testes que des algos... ce n'est pas représentatif de la majorité des applications que les utilisateurs emploient.

              qu'un langage soit x plus rapide que l'autre de nos jours pour la majorité des programmes, ça n'a pas une grosses importances

              java est devenu si populaire car il réduit considérablement le temps de développement

              www.solutions-norenda.com

  • # Et Mono ?

    Posté par (page perso) . Évalué à 3.

    Salut,

    c'est marrant mais ça me fait penser à un rapport de bug (demande d'amélioration plutôt) que j'ai envoyé.

    http://qa.openoffice.org/issues/show_bug.cgi?id=36417(...)

    L'idée c'est de faire reposer OOo sur Mono plutôt que Java.
    IKVM http://www.ikvm.net/(...) pourrait être envisagé.

    L'intéret serait de proposer en plus d'autres langages de script pour piloter OOo.

    Vous pouvez bien entendu voter pour cette proposition...

    @+

    PS : non ça n'est pas un n-ième troll Java vs Mono
    • [^] # Re: Et Mono ?

      Posté par . Évalué à 1.

      pkoi pas faire reposer OOo sur mono ET java :)

      On a juste un tout une discution sur les "problèmes" de Mono et on a eu une conclusion qui était: "en gros, java et mono ont tous les deux des gros problèmes" :)

      http://about.me/straumat

      • [^] # Re: Et Mono ?

        Posté par . Évalué à -1.

        Java en a moins. Du moins, gcj a moins de problème que mono (brevets).
        • [^] # Re: Et Mono ?

          Posté par (page perso) . Évalué à 2.

          et plus on fera d'OOo un hybride plus il sera lourd à installer et (probablement) plus il y aura de problèmes, de bugs difficiles à identifier, etc.
  • # traduire en python ?

    Posté par (page perso) . Évalué à 1.

    Moi je propose un grand challenge. On publie tous les fichiers Java de OOo avec leurs spécifications exactes.

    Et chaque participant doit traduire en python un ou plusieurs fichiers.

    Possible ?
    • [^] # Re: traduire en python ?

      Posté par . Évalué à 2.

      pourquoi perdre son temps?

      autant donner un coup de main à d'autre projets qui apportent quelques choses..
      open office n'a pas beaucoup innové...c'est surtout de star office d'où proviennent les fonctionnalités d'oOo..


      autant travaillé sur des outils fonctionnels qui convertissent les formats propriétaires en formats libres..et vice versa..

      open office est une usine à gaz..autant partir du bon pied et eviter les même erreurs
  • # Je ne vous jette pas la pierre, Pierre

    Posté par . Évalué à 5.

    Juste un petit commentaire pour dire que selon moi il faut être un peu pragmatique.
    Je suis complêtement Stallman lorsqu'il rapelle que Java n'est pas encore libre, car il est important de le rappeller. Toutefois je salut aussi RedHat qui fait des efforts pour faire aboutir gcj et classpath.
    En effet, la communauté Java est pleine de projets libres et de développeurs qui ont été attiré par les idées du libre. Or Java représente presque une communauté avec une certaine culture. Cette culture est composée d'idées partagées aussi par d'autres communautés et d'autres plus différentes, mais le fait est qu'il y a une forte marque identitaire. (parmis ces idées : Ejb, serveur d'appli, Junit, design pattern, forte présence de xml...)
    Il ne faut donc pas "cracher" sur ces communautés (ou ce qu'elles produisent) mais bien comprendre comment les intégrer, comment se libérer de la dépendence au propriétaire.
    Sûr qu'une libération de la jvm de Sun ou de IBM serait une super nouvelle. En attendant, je pense vraiment que classPath est une initiative a booster. En effet, si elle passe les tests de compatibilité de la jvm, elle aura le droit aux brevets.
    Quoiqu'il en soit, Sun pour l'instant s'est montré tolérant envers gcj et je pense qu'il le resterons (je suis d'accord qu'il y a toujours un risque).

    Bien sur pour ma part, beaucoup plus que Java, Python R0x0R à donf !
    • [^] # Re: Je ne vous jette pas la pierre, Pierre

      Posté par . Évalué à 3.

      Il se pourrait que gcj passe les tests de compatibilité de la jvm, d'ailleurs: sun avait parler d«ouvrir» son JCK.
      Un développeur Classpath les a pris au mot, mais ça n'a pas vraiment bougé: http://svn.ghostscript.com/person/robilad/diary.html?start=64(...) .

      En réalité, le développement de Classpath est déjà fortement basé sur des tests - cf japitools pour la couverture des API et surtout Mauve, pour la conformance des API - voir les résultats sur kaffe.org par exemple.

      La seule différence, c'est que tant que sun n'aura pas permis d'utiliser leurs tests l'on n'a pas le droit (tm) d'utiliser le mot java pour des projets comme kaffe et gcj.
  • # OpenOffice a-t-il une alternative libre ?

    Posté par . Évalué à 6.

    OpenOffice a-t-il une alternative libre ?

    Avant qu'openoffice ne fut "libéré" par SUN, il n'y avait pas de suite bureatique convenable. Le libre avait pour les tenants de Gnome Abiword/Gnumeric et pour ceux de KDE KOffice. Ces deux solutions étaeint certe encensés sur certains forum mais la réalité était beaucoup moins rose.

    Ils étaient prometteurs mais bon pour un usage professionnel franchement insuffisant ou incomplet.

    Quand OpenOffice est apparu, l'usage de Linux comme desktop professionnel est devenu vraiment possible.

    Il est certain que les 2 protagonistes Abiword/Gnumeric Koffice se sont bonifiés avec les années, mais ils n'ont pas encore atteints le niveau d' OpenOffice....
    • [^] # Re: OpenOffice a-t-il une alternative libre ?

      Posté par . Évalué à 3.

      Certes Abiword et Gnumeric sont de belles applications indépendantes mais ne forment pas une suite bureautique. Genre éditer une feuille de calcul Gnumeric à l'intérieur d'un texte dans Abiword. De plus il manque un outil de présentation, un outil de dessin/image, un outil de gestion de données vers un sgbd etc. Le tout homogène et avec un "bus" pour gerer les actions de types "embedded".
      Koffice me semble plus interessant meme ça parait encore incomplet. Il ya la version 1.4 qui devrait sortir d'ici 1 ou 2 mois. A voir sans doute http://koffice.kde.org(...)
      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 3.

        De plus il manque un outil de présentation

        Il y en a un en projet, avec un nom à coucher dehors... heu... attends... criamips... acrivips... Ah oui voilà : criawips.
        http://www.nongnu.org/criawips/(...)
      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 1.

        La 1.4 devrait marquer des progrès certains, même si ça restera pas utilisable en prod

        Kword ne sera pas réellement utilisable avant KOffice 2.0 puisqu'il n'est pas WYSIWYG à cause d'un bug qui sera corrigé dans Qt4

        KSpread est plaisant à l'heure actuelle mais un peu léger au niveau des formules proposées

        Les autres modules, j'ai pas testé intensivement

        Mais j'attends énormément de Krita, un logiciel de retouche qui sera dispo pour la première fois dans Koffice 1.4. Son ergonomie est parail il excellente. Par contre question fonctionnalités, ils n'auront pas le temps d'implémenter une foule de choses du type calques d'ici la sortie. Donc bon là aussi, attendre Koffice 2.0
    • [^] # Re: OpenOffice a-t-il une alternative libre ?

      Posté par . Évalué à 1.

      mais ils n'ont pas encore atteints le niveau d' OpenOffice....


      Ca dépend pour quoi faire. Par exemple : je veux tracer une courbe représentant un cosinus bruité :
      - une colonne A telle que A(0)=0; A(n+1)=A(n)+pi/256
      - une colonne B tq B(n) = rand()
      - une colonne C tq C(n) = cos(A(n)) + B(n)

      Tracer C=f(A) pour 0 <= n <= 100, puis 1000, voire 10000

      Fait le test avec OOo, koffice et gnumeric, et dis-moi ce que tu en penses...

      Oui je sais, c'est pas flatteur pour OOo (testé avec 1.3 et 1.4), ni même kspread.


      David
      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 2.

        En voila un qui cherche le détail qui tue.
        Ils n'ont toujours pas compris que gnumeric est un tableur certe reussi mais de loin pas une suite bureautique.
        Deplus Gnumeric n'est pas indépendant. Il a besoin de libs de gnome pour fonctionner. Ce qui est pour ceux qui ne veulent pas de Gnome et ils sont nombreux un défaut certain !!!



      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 1.

        J'ai plusieurs fois eu recours à Excel parce que le tableur d'OOo était pas foutu de traiter toutes les données de ma feuille pour tracer une courbe :(
      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 2.

        T'as pas essayé avec gnuplot ?

        Du style :
        --- gnuplot ---
        set xrange [0:10000]
        plot cos(x*pi/256)+rand(0)
        ---

        Pour avoir un nuage de points, tu peux faire en deux temps :
        --- shell ---
        date +%s |
        gawk '
        { srand($1); PI=2*atan2(1, 0) }
        END { for (i = 0; i < 10000; i++) print cos(i*PI/256)+rand() } > data
        --- gnuplot ---
        plot 'data'
        ---
        (On peut aussi générer un seul fichier avec les commandes gnuplot idoines au début et piper tout ça dans gnuplot pour en faire un .eps.)

        Small is beautiful.
      • [^] # Re: OpenOffice a-t-il une alternative libre ?

        Posté par . Évalué à 1.

        Bonjour,


        - une colonne A telle que A(0)=0; A(n+1)=A(n)+pi/256
        - une colonne B tq B(n) = rand()
        - une colonne C tq C(n) = cos(A(n)) + B(n)

        Tracer C=f(A) pour 0 <= n <= 100, puis 1000, voire 10000


        Quel est le problème ? OOo 1.1.4
        Je viens de le faire pour n = 1000 et 5000 et ne vois rien de choquant à premiere vue.

        Maintenant, je n'ai pas encore pris mon café ....

        Si probleme il y a, a t il été remonté ? Numero d'issue ?

        Laurent
        • [^] # Re: OpenOffice a-t-il une alternative libre ?

          Posté par . Évalué à 2.

          Le problème c'est que le temps que met OOo à tracer cette courbe est ridiculement long.
          Sur ma machine au taf (Celeron 2.4GHz 512Mo), cela prend au moins 1 minute (n=1000 avec OOo 1.1.3), de même si je redimensionne le graphe généré. D'accord, je suis tous les jours stupéfait de voir à quel point cette machine est lente pour les caractéristiques affichées. Mais quand même.

          Pour répondre au post précédant : bien sûr que j'utilise Gnupot (ou Python avec matplotlib, ou autres) pour faire ce genre de trucs.
          Mon exemple n'est pas un cas réel de mes besoins, juste un exemple.

          David
          • [^] # Re: OpenOffice a-t-il une alternative libre ?

            Posté par . Évalué à 1.

            Je viens de passer à 10 000

            je ne vois de reele latence que lorsque je demande une recolorisation des points. Effectivement, il prend quelques secondes (2 à 3)
            La machine est un centrino 1,7 GHz, 512 Mo ram sous debian

            Aucun probleme particulier sur un redimensionnement
            As tu regardé tes options de gestions d'objets graphiques ? peut etre que ca aiderait ? (outils > options > memoire vive) mais si tu as laissé les valeurs par defaut, ce devrait etre bon (c'est mon cas ...)

            Laurent
            • [^] # Re: OpenOffice a-t-il une alternative libre ?

              Posté par . Évalué à 1.

              Alors là ça m'intéresse. Comment est-ce possible que faire la même chose sur ma machine au taf (de puissance à peu près équivalente) prend plus d'une minute quand cela prend qqs secondes chez toi ?

              Je suis en train de rafaire le test : j'ai une colonne de 1000 chiffre, je la sélectionne, je demande un graphe (toutes options par défaut), données ofganisées par colonne.

              Entre le moment où je clique sur 'Créer' et celui où apparait un graphe, le CPU est à 100%, la mémoire ne bouge pas, et il faut 1 à 2 mn pour avoir un résultat.
              En plus, le résultat est inexploitable car l'axe des X est illisible et non paramétrable (quant aux valeurs min, max, et nombre d'étiquettes).
              En fait, il semble bien que le problème est lié à l'affichage de cet axe des X (je vais explorer un peu cela).

              David
            • [^] # Re: OpenOffice a-t-il une alternative libre ?

              Posté par (page perso) . Évalué à 0.

              la création du graphique avec 10 000 point sur un 1800+, 512Mo de ram se fait en même pas 1 sec

              www.solutions-norenda.com

          • [^] # Re: OpenOffice a-t-il une alternative libre ?

            Posté par . Évalué à 2.

            Pour répondre au post précédant : bien sûr que j'utilise Gnupot (ou Python avec matplotlib, ou autres) pour faire ce genre de trucs.
            Mon exemple n'est pas un cas réel de mes besoins, juste un exemple.

            Ben, c'était justement ce que je lui reprochais à ton exemple : tu te plains de la lenteur d'OOo et tu cites plusieurs tableurs à comparer avec lui à partir d'un exemple qui n'est pas (à mon avis) dans les besoins pour lesquels un tableur devrait être utilisé.

            Je voulais donc signaler la présence d'outils spécialisés dans le tracé de courbes et demandais donc si :
            - tu les connaissais ;
            - tu les reconnaissais (comme « étudiés pour ») ;
            - tu avais aussi comparé les performances de ces outils à celles des tableurs.

            L'esprit était donc plutôt : on peut faire pas mal de choses avec un tableur mais est-ce une raison pour lui faire faire n'importe quoi, et, surtout, est-ce une raison pour s'en plaindre ?

            Maintenant, c'est vrai que OOo est lourd ;o)
            • [^] # Re: OpenOffice a-t-il une alternative libre ?

              Posté par . Évalué à 1.

              Le commun des utilisateurs s'attend à pouvoit tracer une courbe ou un camembert simplement avec son tableur. Et une courbe de 1000 points ce n'est pas une grosse courbe.

              Perso, je n'aime pas les tableurs. Quand je veux faire du traitement statistique, j'utilise R, ou Octave pour des maths, etc.
              Mais si OOo est voué à être diffusé largement, à être utilisé en entreprise, ce genre de dysfonctionnement est grave, car c'est une fonctionalité de base d'un tableur, et cela nuit à l'ensemble de l'outil, car (comme c'est un truc de base), beaucoup de gens vont y être confrontés et finir par être obligés d'utiliser Microsoft Excel ou Gnumeric pour "finir" leur travail.
              C'est dommage, car cela ternit l'ensemble de l'outil qui a de grandes qualités. C'est dommage que cela ne soit pas réglé pour la version qui pointe son nez (j'ai testé avec la version 1.9.69 sous Microsoft Windows et sous Linux).

              David
              • [^] # Re: OpenOffice a-t-il une alternative libre ?

                Posté par (page perso) . Évalué à 1.

                posté au moins votre feuille de calcul pour ainsi voir si vous calculer les mêmes chose de la même façon..

                de plus plusieurs pourront tester

                www.solutions-norenda.com

                • [^] # Re: OpenOffice a-t-il une alternative libre ?

                  Posté par . Évalué à 1.

                  Oui !! Je suis preneur du fichier qui pose probleme (mail ou url)
                  Pour ma part, le fichier que j'ai utilisé est ici

                  http://ooo.lab-project.net/~lgodard/calc_cos/(...)

                  Laurent
                  • [^] # Re: OpenOffice a-t-il une alternative libre ?

                    Posté par . Évalué à 3.

                    Ayé les copains, j'ai compris.

                    Pour l'essentiel, la réponse à mon problème est : "je suis un âne".
                    En fait, je demandais un graphe de type "lignes" avec la première colonne comme étiquettes, et non un graphe de type "X-Y".

                    C'est ballo, et je suis un peu rouge de confusion. Cela dit, je pense ne pas avoir été le seul à me faire avoir (ce qui, si cela s'avère être le cas, peut être une source de mécontentement vis-à-vis de ce logiciel pour l'utilisateur occasionnel). J'ai pas testé sous MS Excel pour voir quel est son comportement pas défaut et donc quelle va être l'attitude a priori d'un utilisateur dans un cas similaire).

                    Cela prouve juste que je fais vraiment jamais de graphes avec un tableur, et que je ferais bien de mieux tester les fonctionnalités d'un soft avant de lancer de telles accusations.

                    David (qui va se coucher peut-être un peu moins bête ce soir, et peut-être bien proprio aussi, sait-on jamais, mais ca n'a rien à voir).

                    PS : je viens de tester avec MS Office 2000. Si je demande un graphe de base (lignes), et que j'affecte la première colonne à l'axe des X, il se comporte globalement de la même manière que si je demande un graphe type "nuage de points" (donc XY). Les possibilités de paramétrage de l'axe des X sont un peu différentes dans ces deux cas. Mais la tableur propriétaire s'en sort normalement (donc génère le graphe instantanément), contrairement à OOo. Du coup, je m'en va aller voir si un bug/wish existe, et en créer un sinon. Le problème de OOo est qu'il génrère un axe des X avec toutes les étiquettes, quand bien même un mauvais paramétrage du graphe implique une densité d'étiquettes (tics et labels de tics) ridicule (afficher 10000 tics sur un graphe de 10cm de large est ridicule). Et c'est cela qui le met dans les choux.
  • # Et OOo 1.1 ? Il n'est pas mort que je sache ?

    Posté par (page perso) . Évalué à 2.

    Bonjour,

    Il y avait plusieurs points qui me semblaient intéressants dans OOo 2.0 mais si le tout dépend de Java, c'est moins pratique et moins libre effectivement.

    Ceci étant, la version actuelle d'OOo me convient parfaitement ou peu s'en faut et il n'y a pas de raison critique pour que j'en change.

    Reste qu'il y a un débat de fond derrière tout cela... Là je ne vois pas réponse immédiate.
  • # kaffe ?

    Posté par . Évalué à 2.

    Là c'est une question de grand béotien...

    Je ne suis pas sûr d'avoir compris tous les tenants et les aboutissants de cette dépêche et des quelques commentaires que j'ai lu.

    Est-il possible d'utiliser OOo 2.0 avec Kaffe ?
    - Si oui: quels sont les problèmes de licence (puisque Kaffe est GPL)
    - Si non... Ben heu... Pourquoi ? (c'est sans doute ça que je n'ai pas compris ! :o)
    • [^] # Re: kaffe ?

      Posté par . Évalué à 2.

      Pour kaffe je ne sais pas, mais pour gcj ca avance ... :)

      http://www.spindazzle.org/green/index.php?p=43(...)

      En fait le gros interêt de ce débat va sans être de relancer les travaux sur ce sujet, et c'est déjà bien :)

      M
    • [^] # Re: kaffe ?

      Posté par . Évalué à 2.

      Si non... Ben heu... Pourquoi ? (c'est sans doute ça que je n'ai pas compris ! :o)

      L'implem n'est pas complete, donc si OOo utilise ces parties ca plante...

Suivre le flux des commentaires

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