dimanche 20 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java

Posté par Thomas Petazzoni (page perso, ). Modéré le 18 mai 2005.
En mars, une dépêche sur ce site faisait part de la colère montante chez de nombreux utilisateurs et développeurs de Logiciels Libres au sujet de l'utilisation croissante de Java dans OpenOffice.org 2.0. Dans les versions actuelles d'OpenOffice, Java n'est indispensable que pour des fonctionnalités mineures. Dans la version 2 de la suite bureautique, Java deviendrait indispensable pour un grand nombre de fonctionnalités. Cette décision avait fait resurgir le débat autour du pouvoir de Sun sur le projet OpenOffice ainsi que sur les problèmes posés par l'utilisation de Java : disponibilité sur architectures non-x86 et sur systèmes non-Linux.

En réponse, Richard Stallman avait lancé un appel à contribution pour réaliser une version non-dépendante de Java de la suite bureautique, afin de sortir de ce qu'il appelle le Java trap, c'est-à-dire la dépendance d'un Logiciel Libre sur un logiciel non-libre. Face à cet appel, Scott Carr, Documentation and QA Co-Lead du projet OpenOffice.org a démarré un dialogue avec la FSF pour aboutir à une solution plus pertinente qu'un fork. Il a ainsi précisé que le projet OpenOffice accepterait volontiers les contributions de la FSF, a demandé « comment il pouvait aider à créer une meilleure relation entre la communauté OOo et la FSF», en concluant qu'«il aimerait que tous puissent travailler sur OpenOffice pour en faire un meilleur produit plutôt que de créer de multiples forks».

RMS a ensuite appris qu'OpenOffice était sur le point de fonctionner avec GCJ, une implémentation libre de Java. Il a précisé à Scott Carr qu'il souhaitait pouvoir distribuer une version d'OpenOffice sans devoir encourager à l'utilisation de logiciels non-libres. Scott Carr a donc suggéré que la FSF se concentre sur les questions de compatibilité avec GCJ, mais qu'elle participe également à l'amélioration du logiciel en reportant des bugs au sujet de toutes les fonctionnalités inopérantes avec les versions libres de Java.

Richard Stallman est encore sceptique et souhaiterait qu'une position plus claire soit prise par les développeurs d'OpenOffice. Il aimerait par exemple que la compatibilité avec les versions libres de Java soit directement inclue dans les bonnes conduites de développement (guidelines). En tout cas, RMS a depuis mis à jour son appel à contribution, précisant qu'il cherchait des développeurs pour faire fonctionner OpenOffice.org avec GCJ.

> Lire la dépêche (194 commentaires, moyenne: 2,3).  

Vous avez demandé le commentaire #575796.

Les vieilles traditions

Posté par iug () le 18/05/2005 à 09:31. (lien). Évalué à 3.

C'est sympa, on va retrouver les vieilles traditions de pondre du code supplémentaire pour la portabilité.

Ile ne me semble pas que le langage soit adapté à l'utilisation de plusieurs vaiantes. En c/c++ on a un préprocesseur pour ça, mais en Java, comment va-t-on faire.

Des différences existeront à coup sûr entre le Java de GCJ et le Java de Sun. Il faudra se taper des appels à l'API de réflexivité pour voir quel compilo/interpréteur tourne et utiliser des paths différents dans le code pour ça.

Je préfère largement la formule avec préprocesseur, qui permet de voir du premier coup d'oeuil la différence entre le code de traitement et le code de portabilité.

Sinon, la communauté peut toujours créer un préprocesseur pour Java, qu'il faudrait utiliser pour générer des sources compatibles avec l'une ou l'autre des implémentations.

Ca serait comique, une innovation de la communauté qui permettrait d'améliorer la portabilité d'un langage marketé comme étant portable .

  • [^]Re: Les vieilles traditions

    Posté par Yusei (page perso, ) le 18/05/2005 à 09:40. (lien). Évalué à 6.

    Dans la mesure ou OOo contient du code C++, il utilise deja un preprocesseur... rien n'empeche d'utiliser ce meme preprocesseur pour le code Java, il suffit d'adapter les Makefiles.

    • [^]Re: Les vieilles traditions

      Posté par djano () le 18/05/2005 à 16:29. (lien). Évalué à 1.

      Tu veux sans doute parler du compilateur utilise pour compiler OpenOffice qui contient deja un preprocesseur ?
      Oui, mais non.
      Je ne sais pas ce qu'il en est de linux, mais pour compiler OpenOffice sous windows, la marche a suivre, c'est d'utiliser Visual Studio avec le compilateur de Visual C++. En tout cas, c'etait le cas il y a 2 ans, et c'est encore le cas:

      * Windows with Microsoft Visual C++ .NET2003 Compiler
      with Cygwin tools
      - 4nt tools build is currently broken -

      http://tools.openoffice.org/dev_docs/build_windows_tcsh.html(...)

      Donc, sous windows, le preprocesseur, he bien tu ne l'as pas!
      Sauf si Gcj est utilise via cygwin dans ce but, mais pour le moment j'en doute.

      D'ailleurs je ne comprends pas cette dependance, sauf pour raison de performances (je ne pense pas que Gcc produise un meilleur binaire que le compilateur Gcc sous Wintel). D'autant plus que cela compile:
      All branches support the following platforms:

      * Windows
      * Linux (ppc and x86)
      * Solaris (sparc), x86 needs a tinderbox
      * FreeBSD - We need a tinderbox

      All branches support the following compilers:

      * gcc 3.0 -> 3.3
      * jdk 1.4.1

      http://tools.openoffice.org/builds/(...)

      • [^]Re: Les vieilles traditions

        Posté par Yusei (page perso, ) le 18/05/2005 à 18:42. (lien). Évalué à 2.

        Tu veux sans doute parler du compilateur utilise pour compiler OpenOffice qui contient deja un preprocesseur ?


        Je veux parler de cpp, qui est inclus dans gcc mais appelable séparément... mais en y regardant de plus près, cpp a l'air plus proche de la syntaxe C(++) que je ne pensais. Apparemment il n'aime pas être appelé sur un truc qui n'est pas du C(++). Comme Java est proche du C++ au niveau de la forme, ça ne devrait pas poser des problèmes, mais ce n'est peut être pas une si bonne idée.

        «Donc, sous windows, le preprocesseur, he bien tu ne l'as pas!»

        Ça m'étonnerait que Visual C++ ne fournisse pas un pré-processeur, mais il est possible qu'il ne soit pas facilement appelable séparément. De toutes façons, même sous Windows, OOo dépend de Cygwin muni de gcc, qui fournit cpp.

        Par contre effectivement ça a l'air d'être un beau bordel pour compiler sous Windows... je les plains :)

    [^]Re: Les vieilles traditions

    Posté par Olivier Samyn (page perso, ) le 18/05/2005 à 09:54. (lien). Évalué à 5.

    Java est standardisé que je sache... il serait donc ridicule d'ajouter du code pour passer d'une JVM à l'autre.

    A la rigueur, si une fonctionnalité Java n'est pas encore disponible sur GCJ, il faut:
    - soit contourner le problème: implémentation différente n'utilisant que des fonctions de base Java existante sur GCJ. Dans ce cas pas de problème, les fonctionnalités de base existent à fortiori sur les JVM Sun.
    - soit contribuer à GCJ en fournissant une implémentation.

    Donc, en gros, il ne faut pas ajouter du code pour différencier les JVM, mais se limiter aux fonctionnalités disponibles sur les JVM libres.

    • [^]Re: Les vieilles traditions

      Posté par Olivier Samyn (page perso, ) le 18/05/2005 à 09:58. (lien). Évalué à 4.

      je me répond à moi-même avant qu'un troll ne se montre:
      "Java est standardisé que je sache..."
      ...Sous forme de JSR, et de docs publiées (ce sur quoi se base GNU classpath quoi)

      Oui, je sais que la standardisation des API java sont dictées par Sun...

      Mais ça n'empêche pas une autre implémentation, au fonctionnement identique aux JVM Sun, d'être créée...

      • [^]Re: Les vieilles traditions

        Posté par chaperon () le 18/05/2005 à 19:31. (lien). Évalué à 1.

        ... En parlant de traditions,
        il semblerait que OOo utilise des fonctionnalités mal (pas du tout ?) documentées (besoin de confirmer).
        Si c'est bien le cas, on peut toujours attendre que GCJ fasse son travail correctement (ce ne sera pas la faute de GCJ)

        Tiens, ca me rappelle une autre API ... Ah non, dans l'autre, ce sont les bugs qui sont documentés.

        --
        man man, man !

      [^]Re: Les vieilles traditions

      Posté par Julien Damon (page perso, ) le 18/05/2005 à 12:20. (lien). Évalué à 2.

      Ya qu'a demander aux developpeurs de Sun de participer à la qjc...

      ok je --------------->[]

      • [^]Re: Les vieilles traditions

        Posté par revponpuneq () le 18/05/2005 à 13:19. (lien). Évalué à 5.

        C'est dommage de confondre le service marketing (pas toujours très bon) et les développeurs de chez Sun car ces derniers aident quand ils le peuvent (j'ai vu passer quelque chose à ce sujet pas plus tard qu'hier ou aujourd'hui peut-être : modifier wizards pour que gcj compile..).

        Quand j'ai des problèmes, je demande, et on m'aide. C'est très rapide, ce sont bien des développeurs de chez Sun , et je les en remercie.

        --
        eric bachard
        ericb@openoffice.org

    [^]Re: Les vieilles traditions

    Posté par Stéphane TRAUMAT (page perso, ) le 18/05/2005 à 10:13. (lien). Évalué à 1.

    Ce sont des api à impléménter... le prb est que gcj est "en retard". c'est ça le prb.

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0592s (dont 0.0068 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.