[Débat] Implémentations libres de java : sont elles utilisées dans la pratique ?

Posté par  . Modéré par jerome.
Étiquettes :
0
17
jan.
2005
Communauté
En lisant le Debian Weekly News en ce matin, je tombe sur un article concernant l'utilisation des JVM libres.

Michael Koch a estimé que les implémentations libres de Java en sont à un stade permettant d'exécuter des applications majeures ; il a demandé à ce que plus d'utilisateurs travaillent avec ces implémentations et rapportent les bogues. Il a eu l'impression que beaucoup de personnes préfèrent utiliser les implémentations non libres au lieu de rapporter les problèmes avec les paquets libres. Pour une meilleure prise en charge, les gens devraient essayer Kaffe, SableVM, JamVM ou toute autre implémentation Java libre dans Debian.

Je me demandais : quel est aujourd'hui le niveau d'implémentation de ces JVM ? Quelle est leur efficacité par rapport aux implémentations de Sun ou d'IBM ? Quelles grosses applications font-elles tourner ?

Si vous travaillez professionnellement en Java avec ces JVM (ou que vous avez renoncé à les utiliser), dîtes-nous ce qu'il en est actuellement.

Aller plus loin

  • # jvm vs java en natif

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

    La compilation native avec gjc (gcc) et l'utilisation du toolkit SWT (ibm) est aussi une bonne alternative ...

    Ma question, ou en est le portage de java3d, j2me etc ?

    gpg:0x467094BC

    • [^] # Re: jvm vs java en natif

      Posté par  . Évalué à 3.

      Il ne faut pas oublier que l'intérêt de Java, c'est l'indépendance par rapport à la plate-forme d'execution autrement dit le WORA (Write Once Run Anywhere). Le fait que Java présente la plateforme sous-jacente d'une manière abstraite complexifie généralement les API (voir Swing, JMS...) et n'est pas forcément bon pour les performances. Bref cette portabilité au niveau binaire a un prix. Donc lorsqu'on n'est pas intéressé par cette caractéristique (utiliser la compilation en natif avec gcj et SWT qui rompent cette portabilité), autant utiliser directement gcc et GTK ou VxWindows.

      Par contre avoir en open-source un compilateur Java -> byte-code et une machine virtuelle qui sache profiter des spécificités de Linux pour optimiser l'éxecution serait un plus.

      • [^] # Re: jvm vs java en natif

        Posté par  . Évalué à 3.

        tiens, quelqu'un qui n'a jamais utilisé SWT.

        • [^] # Re: jvm vs java en natif

          Posté par  . Évalué à 2.

          A mon goût, SWT est une bonne librairie tant qu'on reste sagement dans le cadre. Par exemple, je trouve que les possibilités de personnaliser les composants graphiques sont limités.

          Pour avoir testé Eclipse sur différentes plate-formes, je trouve que SWT marche
          - très bien sous Windows
          - bien sous MacOS
          - pas terrible sous Linux GTK

          • [^] # Re: jvm vs java en natif

            Posté par  . Évalué à 7.

            Toute mon equipe de développement est sous Debian et utilise Eclipse, personne ne constate de probleme avec swt, donc je pense que tu n'as pas bcp tester eclispe sous debian car nous l'utilisons intensivement ici.

            Les diffrents developpement SWT ne remonte la non plus aucun probleme.

            Ma remarque visait plutot le troll déguisé qui tentait a laisser penser que programmer en SWT c'est abandonné la portabilité ce qui est strictement faux. SWT s'appuie sur un framework commun à toutes les plateformes Java, seul la librairie utilisé poru l'execution change suivant la plateforme et cest la que reside l'utilisation des composants natifs.

            Le fonctionnement de SWT est a rapproché du fonctionnement des JVM: on battit tout le code sur une API commune (language Java pour la JVM, framework SWT pour les GUI) et lors de l'execution le code spécifique à la plateforme se chargera d'utiliser ce qui existe sur le système.

            Ce qui est dommage avec Swing cest qu'il n'exploite pas ce qui existe deja sur la plateforme pour le graphique (ie GTK pour linux) et qu'il prefere batir ses composants sur la plateforme java 'from scratch": on dessine avec les api graphique de java les tableaux, les labels, les champs texte etc etc. alors que tout ces composants ne demandent qu'a etre utilisé: ils seront plus rapides, moins couteux en mémoire, et en plus ils s'intégreront parfaitement au système sur lequel ils seront executés.

            • [^] # Re: jvm vs java en natif

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

              Ce qui est dommage avec Swing cest qu'il n'exploite pas ce qui existe deja sur la plateforme pour le graphique (ie GTK pour linux) et qu'il prefere batir ses composants sur la plateforme java 'from scratch": on dessine avec les api graphique de java les tableaux, les labels, les champs texte etc etc.


              Le but de Swing, c'était de faire des composants graphiques en java et donc indépendant de la plateforme utilisée. Donc on ne va pas dire que c'est domage que ça soit comme ça :)

              Pour utiliser des composants natifs, on utilise AWT si on veut faire "standard Java" ou SWT si on veut un truc plus moderne.
              Pour faire des applis avec exactement le même look'n'feel sur toutes les plateformes, on utilise Swing.

              Il n'y a aucune raison d'opposer Swing et SWT. Les deux ont leur intérêt.

            • [^] # Re: jvm vs java en natif

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

              Toute mon equipe de développement est sous Debian et utilise Eclipse, personne ne constate de probleme avec swt, donc je pense que tu n'as pas bcp tester eclispe sous debian car nous l'utilisons intensivement ici.

              Tu n'as pas du lire correctement ce qu'il a dit, il compare eclipse sur diffèrentes plate-formes et dit que la version linux est la moins bonne. Et c'est vrai, la version gtk2 est franchement une grosse merde(et encore, je trouve que la description est encore trop faible). C'est un veau, elle est lourde et lente, à coté, gecko sous linux passe pour une flêche. La version motif est un peu plus rapide, mais c'est quand même pas terrible.

              Tu lui dis que ton equipe n'a jamais eu de probleme avec, c'est que personne n'a jamais testé d'autre versions.

              • [^] # Re: jvm vs java en natif

                Posté par  . Évalué à 2.

                J'ai utilisé eclipse sous windows depuis les premieres stable de la version 2.0 (la version 1 etait vraiment trop limité)
                j'utilise depuis 6 mois eclipse v3 (version stable - M1->M4) sous linux avec jdk 1.5 depuis quelques mois. désolé mais chezmoicamarche.org mais bon je dois vraiment etre une exception.

                depuis:
                ->le jdk 5 (pour lexecution d'eclipse)
                ->le kernel 2.6 (pour la nouvelle implémentation des threads ET le prehemptive kernel)
                ->le prix relativement bas de la RAM (1024 de ram n'est pas vraiment exceptionnel pour un poste de développeur)
                eclipse tourne ma foi aussi bien que sous windows. non ce n'est pas un fake cest ce que je constate tous les jours. Ah cest sur j'utilise pas un windows manager bouffeur de RAM et de process comme KDE (troll detected). Effectivement sur un poste avec 512Mo de Ram faisant tourner KDE avec Karamba, une console transparante affichant les logs systeme en fond décran et des xterms transparants a gauche a droite va avoir du mal a faire tourner eclipse, cest sur.

                • [^] # Re: jvm vs java en natif

                  Posté par  . Évalué à -6.

                  je sais pas si tu te rends compte, mais pour une fois on s'en bat vraiment. Ici, on parle d'implémentation LIBREKISENBON :o
                  Ton témoignage n'est d'aucune utilité.

                  • [^] # Re: jvm vs java en natif

                    Posté par  . Évalué à -5.

                    D'autant plus que sur un KDE Debian out-of-the-box, Eclipse tourne très bien avec 512 de ram !

                • [^] # Re: jvm vs java en natif

                  Posté par  . Évalué à 6.

                  Moi en installant les drivers proprio de Nvidia j'ai gagné 10 FPS sous eclipse !

                  Ok, ok, je connais la sortie.

            • [^] # Re: jvm vs java en natif

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

              En effet, il n'y a pas de "problèmes" avec SWT/Gtk2, je l'utilise moi même pour tous mes développements Java, pour Eclipse. Mais alors, qu'est ce que c'est lent !!! C'est incroyable la différence entre SWT/Win32 et SWT/Gtk2 niveau perfs (et pas niveau fonctions/stabilité/autre) ... Et non ca vient pas des mes paquets / mon gtk / ma machine (j'ai essayé les paquets officiels / compilé moi même la partie native de swt). Enfin si, de ma machine, parce que peut être que sur une bête de brute on ne voit pas la différence, mais en tout ca s moi je la vois. Et c'est dommage, parce que objectivement Eclipse est plus agréable à utiliser sous Windows malheureusement. On pourrait d'ailleurs dire la même chose de Swing ceci dit, même si c'est un peu moins poussé. C'est dommage, pour tout le reste, la JVM est au moins aussi rapide que sous Windows.

              • [^] # Re: jvm vs java en natif

                Posté par  . Évalué à 1.

                Je trouve que la version 1.5 du JDK de SUN arrange pas mal les choses sous Linux. En tout cas pour Eclipse la différence avec Windows est moins flagrante sur ma machine.

              • [^] # Re: jvm vs java en natif

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


                je voulais juste dire, que chez moi ça rame pas, en 64 bits en tout cas!
                (blackdown jdk et sun jdk...)

          • [^] # pas terrible sous Linux GTK

            Posté par  . Évalué à 1.

            helas je confirme

            sous win la gui te saute a la tete
            mais eclipse rame vraiment sous nux
            qd Tora l'a package (deb http://people.debian.org/~tora/deb...(...))
            j'ai cru que ca venait de son package
            mais non en fait meme maintenant c'est lamentable

            d'un autre cote une fois developpee, il vaut mieux faire tourner une appli sans GUI sous linux

            sinon concernant l'article, j'avoue utilise java-package avec celui de sun

            • [^] # Re: pas terrible sous Linux GTK

              Posté par  . Évalué à 1.

              pour quelques logiciels comme firefox, eclipse ou java, mon experience personnel me tend a n'installer ces logiciels que par des downloads officiels et non pas en apt-get.... en plus pour eclipse, il suffit juste de décompresser l'archive en guise d'installation.

      • [^] # Re: jvm vs java en natif

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

        Tu as déja essayé eclipse ? ou tu dis n'importe koi car tu connais pas :D

        http://about.me/straumat

        • [^] # Re: jvm vs java en natif

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


          Tu as déja essayé eclipse ? ou tu dis n'importe koi car tu connais pas :D

          C'est quoi le rapport ?
          Eclipse fonctionne très bien sur les plateformes pour lesquelles existe une librairie SWt native. Si ça n'est pas le cas, c'est foutu. Or il me semble que SWT est moins largement disponible que la JVM de Sun (qui, elle contient Swing qui fonctionne partout où elle fonctionne, par définition). Et puis, sans vouloir troller à côté de la plaque, au niveau clarté d'API, il n'y a quand même pas photo.

          • [^] # Re: jvm vs java en natif

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

            Or il me semble que SWT est moins largement disponible que la JVM de Sun (qui, elle contient Swing qui fonctionne partout où elle fonctionne, par définition)

            Sauf que SWT est véritablement open source et peut donc être portée sur beaucoup plus d'architecture que la JVM de Sun, d'autant que la partie Java de SWT est complètement compatible avec les implémentations libres de la JVM.

            • [^] # Re: jvm vs java en natif

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


              Sauf que SWT est véritablement open source et peut donc être portée sur beaucoup plus d'architecture que la JVM de Sun,

              Je ne voudrais pas faire mon pasBill pasGates, mais en quoi le fait que SWT soit Open-Source le rend plus portable ? D'accord, si tu veux, tu peux le porter pour un hardware exotique. Mais il me semble, vu de loin, comme ça, que Java est déja disponible sur un nombre d'environnement tout à fait impressionant. Et puis, SWT sans JVM, génial ;-) Oui, bien sûr, ça peut marcher avec une JVM OpenSource, mais il faut aussi la compiler.

              • [^] # Re: jvm vs java en natif

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

                Je ne voudrais pas faire mon pasBill pasGates, mais en quoi le fait que SWT soit Open-Source le rend plus portable ? D'accord, si tu veux, tu peux le porter pour un hardware exotique. Mais il me semble, vu de loin, comme ça, que Java est déja disponible sur un nombre d'environnement tout à fait impressionant.

                Ouai, c'est sûr. Par exemple sous linux PPC ? Non, Java n'est pas disponible sur un nombre d'environnement tout à fait impressionnant, sauf si on prend en compte les versions open source et les versions castrées (lire JME). Si tu ne comprends pas pourquoi le fait d'être open source facilite le portage, je ne peux rien pour toi (un simple indice : si _tu_ as besoin de faire tourner un logiciel libre sur ton environement, _tu_ peux faire les modifications nécessaires).

                Et puis, SWT sans JVM, génial ;-) Oui, bien sûr, ça peut marcher avec une JVM OpenSource, mais il faut aussi la compiler.

                Je me demandais si quelqu'un serait assez ignorant pour répondre ça, et oui, c'est gagné. Alors voilà, un des gros morceaux de Java qui n'existe pas encore complètement en version libre, c'est justement swing. Si on enlève swing, classpath est très complet, tellement complet que combiné à une machine virtuelle il peut faire fonctionner eclipse essentiellemnt car celui-ci n'utilise pas swing. Bref, pour un environnement non supporté par Sun et sa JVM propriétaire, tu peux en général compiler une machine virtuelle et un compilateur java open source (jikes). Comme ceux-ci sont en général écrit en C standard et avec une approche disons posix, la compilation et le portage ne sont pas trop difficiles. Ensuite, tu peux compiler classpath et la partie de java de swt. Reste donc à porter la partie native de SWT, ce qui est le plus difficile (comme toujours). Mais justement, swt existe en version native gtk, donc si tu as gtk, ce n'est pas trop un problème. Et donc tu obtiens ainsi un environement java presque complet.

                • [^] # Re: jvm vs java en natif

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


                  Si tu ne comprends pas pourquoi le fait d'être open source facilite le portage, je ne peux rien pour toi

                  Ca facilite le portage et la compilation, d'accord. Mais l'utilisation est-elle possible ? Et, j'irais plus loin, l'utilisation de logiciels récents ? Sur le site de Red Hat, je vois que Eclipse/GCJ est dispo en version 2.1.0. En revanche, si je me contente de faire tourner Eclipse sur mon JDK par défaut, j'ai quoi ? La 3.0.1 ? La 3.1M8 ? Pour info, la 3.0 date du mois de juin dernier. Alors, oui, je peux utiliser un JDK libre, mais j'en paye le prix. Et je ne parle pas des outils comme Ant, Tomcat et autres ...


                  Je me demandais si quelqu'un serait assez ignorant pour répondre ça, et oui, c'est gagné. Alors voilà, un des gros morceaux de Java qui n'existe pas encore complètement en version libre, c'est justement swing.


                  C'est sûr que, par exemple, java.beans (sur la version équivalente 1.4) qui n'est pas couvert à 100 %, ça ne change rien. Rien qu'avec les manques constatés, je cite : method java.beans.EventHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[]): doesn't throw java.lang.Exception in jdk14, but throws java.lang.Exception in classpath, ça va aider.

                  Et je ne parle pas des javax.rmi.corba, ldap, ...
                  Alors peut-être que Eclipse peut marcher à peu près, mais je n'irais quand même pas foutre les pieds là-dedans.
                  Quant au support de Java 5 ... il n'est même pas évoqué ???
                  Alors comment tu fais, dans ton beau eclipse-gcj (2.1.0) pour faire des applis à la pointe ?

                • [^] # Re: jvm vs java en natif

                  Posté par  . Évalué à 4.

                  Pour mettre tout le monde d'accord, il existe swingwt qui permet d'utiliser swing

                  ou swt comme backend (avec un code programmé pour swing)

      • [^] # Re: jvm vs java en natif

        Posté par  . Évalué à 4.

        Note que tu parles de wxWindows si la portabilité n'est pas recherchée.

        Il faut noter que wxWidgets offre un certain niveau de WORA et une compatibilité source et non pas binaire mais peux permettre de produire une application multi-plateforme très performante puisqu'en code natif.

        De plus, wxWidgets propose des classes d'abstraction pour le réseau et les threads et çà peux être une très bonne alternative à Java même pour développer des applications portables.

        • [^] # Re: jvm vs java en natif

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

          > une application multi-plateforme très performante puisqu'en code natif.

          Moui, l'affirmation est un peu legere. Par exemple sous windows, wxWidgets est une couche par dessus MFC qui est une couche par dessus win32 qui lui utilise directement le gdi.

          A cote, Qt utilise directement le gdi. Devine lequel est le plus performant ? Le plus facile a optimiser ?


          Idem cote unix, wxWidgets arrive au dessus de gtk.

          • [^] # Re: jvm vs java en natif

            Posté par  . Évalué à 10.

            Moui, l'affirmation est un peu legere. Par exemple sous windows, wxWidgets est une couche par dessus MFC qui est une couche par dessus win32 qui lui utilise directement le gdi.

            N'importe quoi ! WxWidgets n'est pas une couche au dessus de MFC, c'est une API de développement similaire à MFC mais qui ne l'utilise pas. Et puis GDI fait partie de l'API Win32, WxWidgets l'utilise directement, tout comme QT.

            A cote, Qt utilise directement le gdi. Devine lequel est le plus performant ? Le plus facile a optimiser ?

            La différence c'est que QT dessine lui-même les widgets alors que WxWidgets utilise les widgets natifs sous MS Windows. Ce qui fait que WxWidgets permet à une application d'avoir un look natif sous MS Windows, contrairement à QT et à la plupart des librairies similaires sous MS Windows. Alors, lequel est le plus performant ?

            Voir http://wiki.wxwidgets.org/wiki.pl?WxWidgets_Compared_To_Other_Toolk(...) pour plus d'informations.

      • [^] # Re: jvm vs java en natif

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

        Il ne faut pas oublier que l'intérêt de Java, c'est l'indépendance par rapport à la plate-forme d'execution autrement dit le WORA (Write Once Run Anywhere).

        Ouai, bof. L'intérêt de Java, pour moi c'est tout le reste, les API qui couvrent presque tous mes besoins, un langage de haut niveau, etc. La portabilité existe dans de très nombreux autres langages, donc ce n'est vraiment pas un argument.

        Par contre avoir en open-source un compilateur Java -> byte-code
        C'est à dire Jikes ? On voit que tu maîtrises le sujet...

        et une machine virtuelle qui sache profiter des spécificités de Linux pour optimiser l'éxecution serait un plus.

        Euh, c'est quoi les spécificité de linux dont une machine virtuelle pourrait profiter ? Par rapport aux spécificités du hardware, ça ne doit pas être très important en terme de perfs...

    • [^] # Re: jvm vs java en natif

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


      La compilation native avec gjc (gcc) et l'utilisation du toolkit SWT (ibm) est aussi une bonne alternative ...

      Ca présente l'avantage de garantir la non-portabilité.
      On passe du Write Once Run Everywhere au beaucoup plus avantageux Write Once Compile Everywhere.
      Surtout qu'il n'y a aucun avantage en terme de performance.

  • # Pour ce qui est de gcj.....

    Posté par  . Évalué à 7.

    Gcj est une des implémentations libre de java les plus populaires et avancées. C'est celle qui a ma préférence.
    Néanmoins, elle pose un gros probleme: elle ne se comporte pas comme les implémentations de référence.
    Aussi est il meme assez dificile de l'utiliser pour faire tourner des applications non prévues pour: On ne sais tout simplement pas comment faire pour les compiler avec gcj. Un howto sur ce sujet serais le bienvenu.
    Ce qui serait aussi le bienvenu, ce serais que les différents projets libres basés sur java (apache, objectweb, eclipse) prennent en compte gcj et les autres impléméntations libres: qu'ils contribuent à l'écriture des classes manquantes ou incompletes, qu'ils concoivent des buildscripts adaptés a gcj, qu'ils envoient des bugreports et la liste des classes dont elles ont besoins aux concepteurs des java libres.
    Avec quelques efforts de la part de tous, nul doute que des progrès énormes, et bénéfiques pour tous arriveraient très vite. Mais bon, c'est tellement plus simple de se reposer sur une jvm gratuite fournie par sun, en croisant les doigts pour que celui ci ne fasse pas de coup bas.

    • [^] # Re: Pour ce qui est de gcj.....

      Posté par  . Évalué à 1.

      Le plus simple serait de pouvoir remplacer une cible javac par une cible gcj dans les "scripts" ANT...
      Bon pour ceux qui connaissent pas, ANT est l'équivalent d'un makefile pour java. on peut faire énnooorrrmément de chose ( manque plus que le caffé -kaffe?- au dernière nouvelle).

      Quand on compile, on demande d'utiliser javac pour compiler un fichier .java.
      Si un appel à javac pouvait etre remplacer par un appel à gcj, ca serait beaucoup plus simple....

      PS : je ne suis pas un pro de ant, peut-etre que les mots sont mal choisi (parle-t-on de cible javac et cible ant ?)

      • [^] # Re: Pour ce qui est de gcj.....

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

        Mmm, je dois être un peu réac mais je comprend mal l'intérêt d'ANT... A l'extrême limite si le but avait été de faire un truc hyper simple et limité pour éviter d'avoir à apprendre les arcanes de make pour les projets simples (et encore les Makefile simples ça existe...), mais pour ce qui est de la flexibilité et de la puissance, hum bof, avant de rattraper make faut quand même réinventer pas mal de fois la roue.

        A l'extrême limite peut-être les fichiers ANT sont plus "descriptifs", lisibles et moins "orientés commande" que les Makefile. M'enfin moi je trouve que le texte brut "à la Makefile" est tout aussi lisible que du XML avec du bruit de fond en forme de balises.

        Mais ça reste un avis personnel.

        Noter que je me suis cassé les dents pas mal de fois sur make (le célèbre coup du tab remplacé par 8 espaces qui fout tout par terre...) mais à la réflexion c'est peut-être la solution la moins pire.

        Ah oui et sinon pour cadrer avec le débat général: en ce qui me concerne pour de la production les JVMs c'est malheureusement Sun ou IBM, les JVMs libres ne permettant pas de lancer les derniers programmes Java qui sont malheureusement ceux qu'on aurait besoin de lancer. Donc si j'ai moyen de contourner et d'utiliser autre chose que Java, j'achète.

        • [^] # Re: Pour ce qui est de gcj.....

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

          Beh un des avantages est que tout le monde peut développer des extensions portables... style une extension pour copier en ssh un fichier sur le serveur...
          avec make, tu dois développer un outil à part et le porter sur toutes les plateformes !
          la, tu développes ta tâche ant et hop, une fonctionnalité de plus

          http://about.me/straumat

        • [^] # Re: Pour ce qui est de gcj.....

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

          A l'extrême limite peut-être les fichiers ANT sont plus "descriptifs", lisibles et moins "orientés commande" que les Makefile
          Si tu as le temps, jette un oeil a maven, c'est completement ca. Tu as un xml qui décrit ton projet, tes dépendances, etc, et c'est tout, ca suffit a compiler ton projet et le déployer dans la plupart des cas.

          Quand ca ne suffit pas, tu peux rajouter du ant ou du jelly pour des choses un peu particulieres, mais dans le cas le plus courant le descriptif suffit.

        • [^] # Re: Pour ce qui est de gcj.....

          Posté par  . Évalué à 3.

          Justement, c'est déclaratif. Et ça donne deux avantages:
          1 - C'est portable; une cible javac va invoquer le bon compilateur avec les bons arguments. Si tu compare avec les Makefile, ils sont tellement pas portables que autoconf est obligé de les régénérer pour chaque platforme, en définissant des gazillions de variables comme MV, CC, AWK, CCDPMODE, ECHO_N, ac_ct_AR, LN_S. Les commandes de make sont des commandes interprétées par le shell et elles sont donc sensibles à tous les petits problèmes de quotes du shell et à toutes les petites incompatibilités entre les versions GNU, BSD et autres. Ant se contente d'utiliser une API portable.
          2 - On peut facilement l'analyser; le graphe des dépendances est stocké explicitement dans le format XML, donc on peut l'utiliser pour des requêtes comme lister tous les fichiers qui dépendent de tel source. Si tu as une commande gcc test.c -o test.o, make ne peut pas deviner que test.o dépend de test.c, a moins qu'on lui indique explicitement.

          • [^] # Re: Pour ce qui est de gcj.....

            Posté par  . Évalué à 3.

            Si tu as une commande gcc test.c -o test.o, make ne peut pas deviner que test.o dépend de test.c, a moins qu'on lui indique explicitement.
            Ben justement dans le makefile tu met les dependances pas les commandes, tout comme dans ant...


            $cat Makefile
            test: test.o
            $make
            cc -c -o test.o test.c
            cc test.o -o test

  • # Tests...

    Posté par  . Évalué à 3.

    Déjà, est-ce qu'il existe une appli test qui ne fait rien d'autre que tenter de mettre la java machine à genoux, ça nous ferait une idée?

    Sinon on se répartit les 3, on installe tous un quake-java et on fait un match par équipe, celle qui gagne a la meilleure java machine!
    Hein?
    Ah oui...
    ~~~~>[]

    • [^] # Re: Tests...

      Posté par  . Évalué à 1.

      et bien, la suite de test pour valider une implémentation Java est hors de prix. Voir les articles précédents sur Java.

      • [^] # Re: Tests...

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

        C'est faux. Elle n'est pas disponible sous une licence libre, loin s'en faut, mais elle est disponible gratuitement pour des organismes comme la fondation Apache ou le consortium ObjectWeb. C'est insupportable de lire toujours les mêmes conneries sur Java.

  • # Java libre

    Posté par  . Évalué à 5.

    Red Hat/Fedora bosse beaucoup sur gcj. En fait, les autres vm n'ont pas leur "attention".

    Pour FC4, il y aura java "out of the box" (ou presque) avec jpackage qui utilise gcj, eclipse, libgnome-java, libgtk-java, libgconf...

    Ça va peut être donner un coup de boost à gcj.

  • # Rien compris

    Posté par  . Évalué à 2.

    On parle d'une alternative à j2re?

    • [^] # Re: Rien compris

      Posté par  . Évalué à 1.

      On parle d'une alternative à j2re?

      Non, d'une implémentation libre de jre qui soit compatible / conforme aux spécifications officielles, et non de spécifications alternatives (si j'ai bien compris le sens de ta question).

      Bien qu'étant sous une licence de type Open Source, l'implémentation Sun / Blackdown de la MVJ pour Linux n'est pas libre.
      Ce n'est pas la licence, mais cette page en expose les principes : http://www.sun.com/software/communitysource/principles.html(...)

      • [^] # Re: Rien compris

        Posté par  . Évalué à 3.

        Je reformule ma question :
        Cela veut-il dire qu'il est possible qu'un package libre (rpm pour ma mandrake) sorte un jour, soit distribué avec la distrib et m'évite ainsi d'aller sur www.java.com pour télécharger et installer à la "console" le runtime JAVA?

        • [^] # Re: Rien compris

          Posté par  . Évalué à 1.

          ben c'est possible, oui.
          de la a dire que ca va arriver, va ptetre falloir que tu rereformules ta question pour avoir une reponse qui te convient :))

  • # Problème avec la licence de Sun

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

    J'ai eu un moment l'envie de participer au projet (implémenter des classes surtout pour réimlpémenter Swing) mais... Comme j'ai cliqué un jour sur "J'accepte la license de Sun" (et que j'ai regardé quelques sources du code swing), mon cerveau est pollué par la propriété intellectuelle de Sun.

    Ouin...

    • [^] # Re: Problème avec la licence de Sun

      Posté par  . Évalué à 3.

      excuse cotée provisoirement au 8eme degré de l'échelle de Branlowsky-Bidonovitch, qui en comporte 11.

      • [^] # Re: Problème avec la licence de Sun

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

        Hmm ... tu es au courant que c'est la politique officielle de GNU Classpath par exemple (voir dans la FAQ : http://www.gnu.org/software/classpath/faq/faq.html#faq3_2(...)). Bon, on est d'accord qu'il pourrait ... hmmm oublier ;) ... qu'il l'a fait pour aider un coup s'il est motivé, m'enfin c'est mal (c).

        • [^] # Re: Problème avec la licence de Sun

          Posté par  . Évalué à 5.

          > m'enfin c'est mal (c).

          mais non, sacré bon sang, c'est tout à fait bien.
          Dans un régime soumis au droit d'auteur, on protège _la lettre_, pas l'esprit, sans quoi Flaubert n'aurait pas lu Balzac, et il n'y aurait pas de Flaubert.

          Ce qui est interdit et éthiquement déplaisant, c'est la copie verbatim ou assimilée verbatim. Et chez nos amis étatsuniens, si la réutilisation d'"idées brevetées" est effectivement interdite, elle est éthiquement parfaitement juste, rien ne t'interdit de les avoir dans la tête.

          Reste les licences-épouvantail qui te font hypotéquer tes génitoires avant de te laisser consulter le code... si certains artifices juridiques doivent pouvoir théoriquement te valoir un procès personnel douteux, et certainement pas l'ablation de tes joyeuses, elles n'affectent pas la légalité du code que tu produis du moment qu'il n'enfreint pas les limites susdites.

          C'est aterrant de voir à quel point cette propagande de la "pollution intellectuelle" touve un terreau fertile jusque chez les défenseurs du logiciel libre ;(

          • [^] # Re: Problème avec la licence de Sun

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

            > Dans un régime soumis au droit d'auteur, on protège _la lettre_, pas l'esprit, sans quoi Flaubert n'aurait pas lu Balzac, et il n'y aurait pas de Flaubert.
            Oui, bien entendu !! Mais dans le monde réel, SCO attaque des utilisateurs de Linux, parce que ... enfin bon tout le monde connait l'histoire, parce que rien. Mais Sun pourrait se servir de ça comme prétexte pour attaquer Classpath, et même s 'il est évident que Sun a tort, ben il faut se défendre, ce que Classpath ne fera pas, ils fermeront la boutique tout simplement. Et puis de toute façon, si c'est la volonté des développeurs de Classpath, c'est qui est mal, c'est de leur mentir.

  • # kaffe n'est pas en reste non plus

    Posté par  . Évalué à 4.

    Je suis sous Debian SID, et kaffe me paraît plus avancé que gcj/gij en terme de complétude (du moins gij explose plus souvent sur des erreurs de cp de package manquants). J'arrive même à faire certains TP d'imagerie. Par contre, c'est toujours lent (remarque, je ne peux pas comparer je suis sur PPC) et j'ai de temps en temps des erreurs de classpath à l'exécution de JAR, et des petites NullPointerException... il n'empêche, avec les versions livrées par Debian SID, FrozenBubble (version JAR) se lance presque : on touche au but !

    • [^] # Re: kaffe n'est pas en reste non plus

      Posté par  . Évalué à -2.

      Je ne connais pas java plus que ca mais d'après ce que je me souviens de mes cours d'ingé, c'est quand meme un comble d'avoir un
      NullPointerException

      dans un langage qui a supprimé les pointeurs (par rapport au C++)!

      • [^] # Re: kaffe n'est pas en reste non plus

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

        Pas du tout... tu crées une variable d'un type objet et tu ne mets rien dedans ? tu as un null dedans non ?? :D pointeurs ou pas, c pareil

        http://about.me/straumat

        • [^] # Re: kaffe n'est pas en reste non plus

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

          Même si sa question est débile dans le contexte précis de Java, on pourrait effectivement avoir un langage qui garantit que dans le code compilé tous les appels de méthode sont faits sur des objets non nuls. D'une part le compilateur pourrait interdire tout appel sur des objets vus comme explicitement nuls et d'autre part interdire de retourner null d'une méthode mais toujours utiliser les exceptions ; pour ce dernier point, ça rendrait sûrement le code plus lourd.

      • [^] # Re: kaffe n'est pas en reste non plus

        Posté par  . Évalué à 2.

        Prend ce code java :

        Vector pouet = null;
        if(pouet.size() >0){
        }


        Devine l'erreur que cela génère ... :p

      • [^] # Re: kaffe n'est pas en reste non plus

        Posté par  . Évalué à 6.

        c'est quand meme un comble d'avoir un NullPointerException dans un langage qui a supprimé les pointeurs

        Java n'a pas supprimé les pointeurs, loin de là. Il a supprimé la gestion manuelle des pointeurs en les masquant, ce qui est tout autre chose.

        • [^] # Re: kaffe n'est pas en reste non plus

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

          > Java n'a pas supprimé les pointeurs

          Je suis pas expert en Java, mais dans ma terminologie, y'a pas de pointeurs en Java, mais il y a des références (qui sont en pratique implementées par des pointeurs). Dans cette optique, l'exception aurait du s'appeler autrement ...

          • [^] # Re: kaffe n'est pas en reste non plus

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

            Le nom de l'exception te montre que ta terminologie est fausse.

          • [^] # Re: kaffe n'est pas en reste non plus

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

            Dans la mesure où toute variable de type Object est initialisée par défaut à quelque chose qui n'est pas un objet valide (null), il n'y a évidemment pas que des références (qui sont par définition des pointeurs valides) en Java, donc on peut très bien parler de pointeur, et tout est très clair ainsi.

            • [^] # Re: kaffe n'est pas en reste non plus

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

              > (qui sont par définition des pointeurs valides)

              Alors y'a pas de references en C++ non plus.

            • [^] # Re: kaffe n'est pas en reste non plus

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

              Après vérification dans les specs officielles de Java, les "variables qui désignent un objet" s'appellent bien des références en Java :

              http://java.sun.com/docs/books/jls/second_edition/html/typesValues.(...)
              The types of the Java programming language are divided into two categories: primitive types and reference types.

              Par contre, pour la définition de la notion de pointeurs en Java, je trouve ça pas clair :

              The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

              ce que je comprends comme "dans la terminologie Java, les mots pointeur et références sont synonymes" ...

              • [^] # Re: kaffe n'est pas en reste non plus

                Posté par  . Évalué à 3.

                Il ne sert à rien d'en débattre, cela n'a jamais été tranché. Comme tout le monde le sait, il y avait au départ une volonté marketing de dire qu'il n'y avait pas de pointeur en Java, parce que qui dit pointeur dit gestion manuelle de l'allocation et la libération de la mémoire.
                La littérature est pleine de contradiction à ce sujet, chaque auteur ayant sa vision des choses.

                Pour réconcillier tout le monde, et se rapprocher des définitions officielles, une référence est une variable contenant un pointeur. La variable est la référence, le pointeur est la valeur de cette variable.
                Pour prendre un exemple :
                Machin m = new Machin();
                m est la référence.
                Si le Machin créé est stocké à l'adresse 0xabcdef, 0xabcdef est le pointeur (qu'on ne manipule jamais en Java).

                Mais au fond on s'en fout un peu, parce que ça ne change rien. Dans la lignée de ces débats stériles, lorsque je passe Machin en paramètre d'une méthode, est-ce un passage par valeur ou par adresse/référence ?

                • [^] # Re: kaffe n'est pas en reste non plus

                  Posté par  . Évalué à 3.

                  Puisque j'en suis à -10 sur le post qui a lancé ce débat à la c..., j'aimerais te plussoyer:

                  il y avait au départ une volonté marketing de dire qu'il n'y avait pas de pointeur en Java


                  J'ai en effet dû avoir le cerveau pollué par le discours marketing et me fourvoyer dans des allégations qui ne sont pas ou plus de mon niveau.

                  Et puis j'aime pas Java!

                • [^] # Re: kaffe n'est pas en reste non plus

                  Posté par  . Évalué à 3.


                  La littérature est pleine de contradiction à ce sujet, chaque auteur
                  ayant sa vision des choses.


                  J'aime bien la vision de Thinking in Java (Bruce Eckel), selon lequel:

                  en Java il y a des références. Bon, remarquez, c'est comme des pointeurs, hein ? Et oui, ce sont des pointeurs, mais débarassés de toute notion d'arithmétique de pointeurs. Des pointeurs, non déplaçables (donc qui ne pointeront jamais vers n'importe quoi).


                  Du jour où j'ai lu ça, moi, j'ai arrêté de me faire des noeuds.

                  Mais au fond on s'en fout un peu, parce que ça ne change rien. Dans la lignée de ces débats stériles, lorsque je passe Machin en paramètre d'une méthode, est-ce un passage par valeur ou par adresse/référence ?


                  Par contre, je n'avais jamais entendu parler de ce troll (ça veut bien dire ça, débat stérile ? :-). La réponse me semble immédiate: l'objet utilisé par la fonction appelé est le même, ie. toute opération effectuée dessus dans la fonction appelée sera vue dans la fonction appelante, une fois qu'on lui aura rendu la main. Les deux fonction référencent le même objet: c'est un passage par référence.

                  A comparer avec un passage d'int en paramètre (ou un autre type natif Java) où, si l'appelé modifie la valeur de son paramètre, cela ne se répercute pas dans la fonction appelante.

                  Itou!

                  • [^] # Re: kaffe n'est pas en reste non plus

                    Posté par  . Évalué à 1.

                    Par contre, je n'avais jamais entendu parler de ce troll (ça veut bien dire ça, débat stérile ? :-). La réponse me semble immédiate: l'objet utilisé par la fonction appelé est le même, ie. toute opération effectuée dessus dans la fonction appelée sera vue dans la fonction appelante, une fois qu'on lui aura rendu la main. Les deux fonction référencent le même objet: c'est un passage par référence.

                    Ben, en fait c'est la même question (et il me semble que Bruce Eckel y fait référence dans sa dernière édition de TIJ) :
                    Si on considere qu'il n'y a que des references, alors, c'est effectivement un passage par référence. Mais les tenants des pointeurs, prétendent que c'est le passage d'un pointeur, donc par valeur.
                    Mais c'est effectivement un débat stérile. L'important est de comprendre ce qui se passe !

                    • [^] # Re: kaffe n'est pas en reste non plus

                      Posté par  . Évalué à 1.


                      Si on considere qu'il n'y a que des references, alors, c'est effectivement un passage par référence. Mais les tenants des pointeurs, prétendent que c'est le passage d'un pointeur, donc par valeur.

                      Ah, ok. En fait, ce qu'il faut dire (àmha) c'est que les objets sont passés par référence, mais que leurs références, elles, sont passées par valeur.

                      Mais c'est effectivement un débat stérile. L'important est de comprendre ce qui se passe !

                      C'est vrai, et je m'excuse d'avoir marché là-dedans. En même temps, il reflète peut-être d'une certaines incompréhension de ce qui se passe de la part des gens qui en débattent. Cela vaut tjs le coup d'expliquer, alors (et hop, je me justifie !)

                      A+

      • [^] # Re: kaffe n'est pas en reste non plus

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

        C'est koi ton école d'ingé ? :D

        http://about.me/straumat

        • [^] # Re: kaffe n'est pas en reste non plus

          Posté par  . Évalué à 1.

          J'ai utilisé des JVM libres lors d'un stage. L'entreprise produisait une petite boite embarquée dans une voiture. Celle-ci tournait avec un processeur ARM et n'ayant pas de JVM non libres sur ARM il a bien fallu prendre de l'open source.

          J'avais finalement retenu kaffe car il gérait QT AWT et dans l'ensemble marchait pas trop mal. Par contre c'est vrai qu'il est relativement lent
          SableVM par contre lui est beaucoup plus rapide.

          Atttention kaffe ne sort presque pas de release et il faut prendre la version CVS si on veut avori qqchose de potable.

  • # blackdown libre ?

    Posté par  . Évalué à 4.

    j'ai pas tout suivi là ...

  • # et java 5.0?

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

    J'ai fait une appli utilisant les nouvelles possibilites de java 5.0, et il me semble que gcj ne sait pas trop quoi en faire ;/ qu'en est il des autres? Il me semble que a part les proprio, pas encore d'alternative pour ca...

  • # Classes manquantes

    Posté par  . Évalué à 5.

    Le problème n'est pas tant au niveau des JVMs mais au niveau des classes manquantes dans classpath. Les JVMs libres se comportent plutot bien d'après ce que j'ai pu tester. Mais à chaque fois que je récupère une appli Java quelconque, qui n'a absolument rien d'exotique ça ne compile pas parce qu'une méthode manque ou n'a pas la signature prévue. Il ne faut pas oublier que classpath vise en priorité la compatibilité Java 1.2, on en en est à Java 1.5. Certaines JVM proposent d'utiliser au choix classpath ou les classes de Sun. Ca peut aider un peu.

    • [^] # Re: Classes manquantes

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

      100% d'accord. Et c'est d'autant plus important que si on excluait les bibliothèques du débat sur la portabilité, le C standard (grâce à GCC) garantirait (en ce qui concerne les projets libres et/ou opensource) une bien meilleure portabilité que Java. Or ce n'est pas le cas, car évidemment quand tu es sous Windows ou UNIX le "tronc commun" de bibliothèques est très réduit. A tel point que pour un problème trivial et récurrent comme la communication réseau via TCP/IP, les APIs ne sont pas les mêmes -> Winsock 2 != Sockets POSIX.

      Donc fondamentalement le nerf de la guerre c'est que les bibliothèques soient les mêmes, et là effectivement il y a un boulot monstre mais fondamental dont classpath est le digne représentant.

  • # Wonka

    Posté par  . Évalué à 2.

    Je pense qu'il est intéressant de regarder Wonka (http://www.acunia.com/wonka/) pour tous ceux qui font du Java embarqué et veulent un JVM libre.

  • # IBM préparerait une JVM libre

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

    http://www.weiqigao.com/blog/2005/01/17/1106011880000.html(...) :)

    eheh je te raconte pas le thread qu'on va avoir ici quand ca va sortir !

    http://about.me/straumat

  • # ey !

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

    Eh vous oubliez une VM libre : IKVM.NET (http://www.ikvm.net/(...))
    :-]

Suivre le flux des commentaires

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