Eclipse compilé en natif.

Posté par . Modéré par Jaimé Ragnagna.
Tags :
0
4
août
2003
Java
Les gurus de gcj chez Red Hat ont réussi à compiler Eclipse en code natif.

Eclipse est un IDE (environnement de développement) écrit en Java.
gcj est un "gcc pour Java" (à savoir un compilateur de "bytecode ou sources Java" vers "code natif").

Désormais, on pourra utiliser ou distribuer Eclipse sans être dépendant d'une quelconque JVM.

Cette prouesse a necessité de patcher Eclipse et gcj, il faudra donc attendre leur prochaine version pour pouvoir faire ça chez soi.


Note: Red Hat avait déjà réussi à compiler en natif d'autres applications Java, comme Tomcat 3, Ant ou Xerces. Le projet en question s'appelait RHUG.
  • # Re: Eclipse compilé en natif.

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

    Moi quand on me parle d'eclipse, je pense desuite a l'eclipse operating system !

    http://www.eclipse-game.com/htm/eos.htm(...)
    • [^] # Re: Eclipse compilé en natif.

      Posté par . Évalué à -1.

      Un soft « pour DOS ou Windows » appelé pompeusement MachinOS? Tiens, ça me rappelle quelque chose ^^
      • [^] # Re: Eclipse compilé en natif.

        Posté par . Évalué à 0.

        Les histoires belges c'est comme les autres : plus elles sont courtes, plus on rit :-)
      • [^] # Re: Eclipse compilé en natif.

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

        effectivement... ca devient une manie ces programmeurs qui ecrivent des systemes d'exploitations ! ;-)

        Ceci dit, j'aime bien le taux de conversion francs/dollars pour s'enregistrer: 350.00 FF ou $90..... (oui, je sais le dollar a été a 5 francs à une époque, mais meme la, ca marche pas...)
    • [^] # Re: Eclipse

      Posté par . Évalué à 10.

      Les gens d'IBM ne s'en cachent pas beaucoup, le nom d'Eclipse n'a pas été choisi au hasard :

      Qu'est ce qui assombrit le soleil ? :)

      Eclipse of sun, ou comment récupérer un peu Java :)

      M
      • [^] # Re: Eclipse

        Posté par . Évalué à 0.

        Ca me rappelle un tract publicitaire que j'ai retrouvé dans un tirroir lors d'un stage chez HP.

        Ca disait "HP is going to eclipse Sun". J'ai été très surpris car le HP Way et tous les documents internes prohibent tout dénigrement de qui que ce soit. C'est d'ailleurs le seul exemple que j'aie d'HP dénigrant qui que ce soit.

        BeOS le faisait il y a 15 ans !

        • [^] # Re: Eclipse

          Posté par . Évalué à 3.

          "HP is going to eclipse Sun" on ne peut pas franchement appeler ça du dénigrement, c'est pas forcément très constructif, mais c'est pas du dénigrement.
          • [^] # Re: Eclipse

            Posté par . Évalué à 2.

            Détrompe-toi ! Étant donné la qualité plus que discutable des produits HP, le fait qu'ils éclipsent ceux de Sun est tellement improbable que c'est purement du dénigrement.

            (ATTENTION: ce message contient une bonne dose d'ironie et dénigre sans vergogne les produits HP)
            • [^] # Re: Eclipse

              Posté par . Évalué à -2.

              Bonjour,

              Je ne suis pas familier de ce site Internet, mais je crois savoir que la législation vous impose une certaine retenue. Non pas que je ne sois pas capable de saisir le caractère humouristique de votre message, mais n'y a-t-il pas une autorité régulatrice sur ce site à même d'en éditer le contenu ?

              Pour la défense de HP, je pense que ces quelques liens vous éclairciront :
              - http://opensource.hp.com/(...) pour quelques projets OpenSource soutenus par HP
              - http://h18002.www1.hp.com/alphaserver/(...) pour une ligne de produits qui n'a rien à envier à la concurrence -- notez ce faisant la présence de SuSE et Red Hat mis en valeur dès la première page.

              Cordialement,
                Jean Michel
              • [^] # Re: Eclipse

                Posté par . Évalué à 3.

                bmc a dit : «Étant donné la qualité plus que discutable des produits HP»

                Jean michel Delafleur a répondu : «Je ne suis pas familier de ce site Internet, mais je crois savoir que la législation vous impose une certaine retenue.»

                Ben quoi, où est le problème monsieur le juge, bmc dit qu'on peut discuter de la qualité des produits HP, ce n'est pas encore interdit dans ce pays, non ?

                De toute façon, Michel Houellebecq serait le premier à vous te (je tutoie tout le monde ici, pourquoi faire exception ? Je ne fais aucune discrimination, qui en l'occurence aurait été négative) contredire sur ce terrain, on a encore le droit de dire ce qu'on pense !!
      • [^] # Re: Eclipse

        Posté par . Évalué à 0.

        Les eclipses lunaires sont franchement plus nombreuses.

        C'était la minute astronomique.
        • [^] # Re: Eclipse

          Posté par . Évalué à 3.

          Faux, dans l'absolu, elles sont légérement moins fréquentes que celles de soleil.
          Mais comme une eclipse de lune est visible sur une plus grande zone (+/- la moitié de la surface terrestre), en un lieu donné elles sont plus nombreuses.

          C'était la correction de la minute astronomique.
  • # Je prefere Netbeans.

    Posté par . Évalué à 3.

    Sur ce moi je prefère Netbeans.

    http://www.neetbeans.org(...)

    Et j'aimerais bien avoir Netbeans compilé avec.

    Et puisqu'on a plus peur de GCJ, Nosica est un projet trés interressant.

    http://www.nosica.net(...)
    • [^] # Re: Je prefere Netbeans.

      Posté par . Évalué à 10.

      Il ne faut pas oublier que gcj utilise GNU Classpath, et que ce dernier n'implémente pas (encore?) la partie Swing de Java.

      Le rapport avec la choucroute étant que Netbeans, à la différence d'Eclipse, est en Swing. Et ça a l'air moins agréable que SWT à faire marcher sous gcj (et en plus c'est moins chouette)
    • [^] # Re: Je prefere Netbeans.

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

      Et puisqu'on a plus peur de GCJ, Nosica est un projet trés interressant.

      Tu trouves vraiment ?
      Tu penses vraiment qu'un mix douteux de ce type, sans aucune réflexion sur le pourquoi de la présence de la surcharge d'opérateurs, de la généricité et d'autres notions complexes et souvent loin d'être intuitives, est vraiment une bonne idée ?
      Pour ma part, je ne trouve pas.
      • [^] # Re: Je prefere Netbeans.

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

        Ben tiens, alors allons y mettons les pieds dans le troll ...

        J'avoue effectivement volontiers que je ne connaissais rien aux compilateurs il y a 2 ans. J'avoue volontiers que j'en apprend sur la compilation et la theorie de la compilation tous les jours.
        J'avoue encore que Nosica est né parce que je m'estime tres bon (oui je sais, les mollets tout ca) en Java et en C++, et que je trouvais que dans l'un comme dans l'autre il y avait des fonctionnalites que j'aimais et d'autres que je n'aimais pas.

        Maintenant puisque ca fait deux ans que je suis dessus et qu'en deux ans je n'y ai toujours pas reflechi, va falloir que t'argumente un peu parce que la ca frise l'insulte et la malhonnetete intellectuelle.
        • [^] # Re: Je prefere Netbeans.

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

          J'avoue encore que Nosica est né parce que je m'estime tres bon (oui je sais, les mollets tout ca) en Java et en C++,
          Tes mollets, je m'en fous, les miens sont largement plus beaux.

          et que je trouvais que dans l'un comme dans l'autre il y avait des fonctionnalites que j'aimais et d'autres que je n'aimais pas.
          Ce qui est donc une justification suffisante pour les introduire dans ton nouveau langage.

          Maintenant puisque ca fait deux ans que je suis dessus et qu'en deux ans je n'y ai toujours pas reflechi, va falloir que t'argumente un peu parce que la ca frise l'insulte et la malhonnetete intellectuelle.
          Non, ce n'est pas de la malhonnêteté, juste une constatation. J'ai parcouru le site web présentant Nosica, et je n'ai vu nulle part de présentation du pourquoi des fonctionnalités implémentées dans ce langage. Par exemple, je ne sais pas pourquoi tu veux implémenter un inutile retour multivarié, alors que tu peux retourner un objet d'une classe donnée.
          De la même manière, aucune explication sur le pourquoi de la surcharge d'opérateur, sur la distinction (apparement assez subtile) entre les références et les types primitifs.
          Je ne cherche pas à t'insulter, mais je trouve sincèrement qu'il n'y a aucune réflexion sur le fond du langage. Tu as trouvé des fonctionnalités cool ici ou là, et tu les as implémentées aussitôt pour en faire ton langage.
          Et pour moi, ne pas donner à son langage une idée motrice me paraît une erreur assez importante.

          Pour te donner un exemple, Java a été créé en conservant un objectif de simplicité, d'où l'absence de l'héritage multiple, de la surcharge d'opérateur, de la généricité.
          • [^] # Re: Je prefere Netbeans.

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

            Ce qui est donc une justification suffisante pour les introduire dans ton nouveau langage.
            Oui largement il me semble. Tu noteras quand même que je n'ai pas intégré tout et n'importe quoi du C++ dans Nosica :-) Et si je n'ai pas tout introduit, peut etre qu'alors il y a une certaine reflexion non ?


            J'ai parcouru le site web présentant Nosica, et je n'ai vu nulle part de présentation du pourquoi des fonctionnalités implémentées dans ce langage

            Effectivement t'as du le parcourir, sinon tu aurais trouvé toutes les infos qui te manque.


            Par exemple, je ne sais pas pourquoi tu veux implémenter un inutile retour multivarié
            Tiens tres bon exemple de chose que je vais apprendre aujourd'hui ...
            C'est quoi un "retour multivarie" ?
            - Est ce qu'il s'agit de surcharge sur le type retour ?
            Si oui, le but etait de permettre des implémentations différentes suivant le type retour. On a essayé, on s'est aperçu que c'etait possible, mais c'etait tres dur de faire du reporting d'erreur lisible. Du coup c'est une fonctionalite qui n'existe plus dans le langage. (depuis à peu près 1 an)
            - Est ce qu'il s'agit de pouvoir retourner plusieurs valeurs ?
            Dans ce cas, je ne comprend pas ce que tu as voulu dire avec ton "retour d'une classe donnée". Creer une classe pour le besoin d'une methode ne me semble pas tres souple. C'est au mieux contraignant. Quel est l'interet des mots clefs 'out' en CORBA dans ce cas ? La detection des E/S dans une methode est un indicateur tres puissant pour pouvoir faire des optimisations. (pureté des méthodes, predictibilité des données, ...)

            aucune explication sur le pourquoi de la surcharge d'opérateur
            Exemple donné dans la doc (si si, il faut lire) : http://www.nosica.net/old/LearningNosica.html#operators(...) Ca sert par exemple a implémenter tous les operateurs sur les types primitifs et natifs. Car ces types ne sont pas des First Class Object.

            sur la distinction (apparement assez subtile) entre les références et les types primitifs
            Encore une fois tu n'as pas lu la doc : http://www.nosica.net/user_zone.php?id=primitive+vs+reference(...)
            et aussi (en Fr) : http://www.nosica.net/user_zone.php?id=FR_primitive+vs+reference(...) ou encore sur l'ancien site : http://www.nosica.net/old/LearningNosica.html#referencesandprimitiv(...)
            Les primitifs sont de petits objets qui permettent par exemple de définir un entier (un jour on pourra définir des entiers sur des plages de valeur). Sémantique d'allocation sur la pile. Les types références sont l'equivalent des types Java : allocation sur le tas, partagé, garbage collecté.

            Je ne cherche pas à t'insulter, mais je trouve sincèrement qu'il n'y a aucune réflexion sur le fond du langage
            Tu m'excuseras, mais essaie de comprendre que passer beaucoup de temps sur un projet, et s'entendre dire par quelqu'un que tu ne connais pas qu'il n'y a pas de réflexion sur le fond du langage ne soit pas tres agréable a entendre. Alors allons-y pour les reflexions sur le fond du langage :
            - Une syntaxe claire (je pourrai dire simple, comme Java)
            - Les fonctionalites que je trouve manquer a Java : nottamment la généricite (et non, je ne trouve pas que Java 1.5 apporte vraiment des réponses a ce niveau là, pour moi il s'agit plus d'une rustine qu'une vrai implémentation de la généricité). Mais aussi la surcharge d'opérateur.
            - covariance sur tous les parametres (but depuis le debut meme si on a trouve la solution théorique que récemment)
            - pas de types prédéfinis (tous les types, y compris ceux de net.nosica.lang sont entierement redéfinissable par l'utilisateur), ce qui explique pourquoi on a besoin de la distinction entre type primitifs/types references et surcharge d'operateur pour ne citer qu'eux.

            Alors oui je ne me cache pas : lorsqu'on trouve une fonctionalité sympa dans un autre langage, on regarde si on peut l'intégrer dans Nosica. Mais non, on ne le fait pas n'importe comment et a n'importe quel prix. On ne le fait qu'apres mûre réflexion et à condition que ça s'integre bien avec le reste du langage. D'ailleurs on passe plus de temps à refuser des fonctionalités qu'à en ajouter. Va faire un tour sur le forum pour t'en faire une idée.

            Java a été créé en conservant un objectif de simplicité
            Tout a fait, et ca en fait un langage sympa, mais parfois aussi plutôt limité lorsque l'on connait d'autres langages (je pense au C++, a Eiffel, mais aussi au Lisp).

            Sinon pour finir, sache que malheureusement je galere enormément à trouver du temps pour m'occuper de Nosica, alors le site oueb et la doc passe en dernier.
            Sache aussi que j'accepte volontiers la critique, mais la critique constructive. A ce titre ton deuxieme post est deja plus satisfaisant. Ceci dit il me semble que tu gagnerais a vraiment étudier le langage pour faire une critique plutôt que "parcourir" le site (critique que j'accepterai sans probleme, je ne cherche qu'a améliorer le langage)
            • [^] # Re: Je prefere Netbeans.

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

              Oui largement il me semble. Tu noteras quand même que je n'ai pas intégré tout et n'importe quoi du C++ dans Nosica :-)
              Encore heureux ! Je me serais sûrement lâché si j'avais vu par exemple des macros ...

              Et si je n'ai pas tout introduit, peut etre qu'alors il y a une certaine reflexion non ?
              Dont on ne distingue ni les prémisces, ni les buts.
              Je m'explique : aussi bien dans la documentation que dans ton message, il n'y a pas de pourquoi (sauf peut-être pour les types primitifs), juste des comment. La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible. On ne trouve dans les différentes adresses que tu donnes que des exemples, mais à aucun moment une justification de la présence de cette fonctionnalité, fort complexe et à mon avis relativement peu utile.

              Tiens tres bon exemple de chose que je vais apprendre aujourd'hui ...
              C'est quoi un "retour multivarie" ?

              Une formulation bancale.

              - Est ce qu'il s'agit de surcharge sur le type retour ?
              Non, même si cette fonctionnalité aurait, elle, été un vrai plus, absent du reste de Java, ce que je regrette chaque jour.

              Si oui, le but etait de permettre des implémentations différentes suivant le type retour. On a essayé, on s'est aperçu que c'etait possible, mais c'etait tres dur de faire du reporting d'erreur lisible. Du coup c'est une fonctionalite qui n'existe plus dans le langage. (depuis à peu près 1 an)
              Dommage, c'aurait été très intéressant.

              - Est ce qu'il s'agit de pouvoir retourner plusieurs valeurs ?
              Oui.

              Dans ce cas, je ne comprend pas ce que tu as voulu dire avec ton "retour d'une classe donnée". Creer une classe pour le besoin d'une methode ne me semble pas tres souple. C'est au mieux contraignant.
              Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.

              Quel est l'interet des mots clefs 'out' en CORBA dans ce cas ? La detection des E/S dans une methode est un indicateur tres puissant pour pouvoir faire des optimisations. (pureté des méthodes, predictibilité des données, ...)
              Je suis désolé, mais je ne vois pas le rapport, même si je suis bien d'accord avec toi pour dire que c'est bien pratique de qualifier clairement les entrées d'une méthode.

              Exemple donné dans la doc (si si, il faut lire) : http://www.nosica.net/old/LearningNosica.html#operators(...(...)) Ca sert par exemple a implémenter tous les operateurs sur les types primitifs et natifs. Car ces types ne sont pas des First Class Object.
              Je ne cherche pas d'exemple, juste une vraie raison. Maintenant que tu me donnes toutes ces informations supplémentaires, effectivement, je comprends l'intérêt de cette surcharge.

              Tu m'excuseras, mais essaie de comprendre que passer beaucoup de temps sur un projet, et s'entendre dire par quelqu'un que tu ne connais pas qu'il n'y a pas de réflexion sur le fond du langage ne soit pas tres agréable a entendre.
              Ca, je veux bien le comprendre, et je m'excuse si mon ton a paru insultant.

              Alors allons-y pour les reflexions sur le fond du langage :
              - Une syntaxe claire (je pourrai dire simple, comme Java)

              Oui, et c'est un très bon point, je trouve.
              - Les fonctionalites que je trouve manquer a Java : nottamment la généricite (et non, je ne trouve pas que Java 1.5 apporte vraiment des réponses a ce niveau là, pour moi il s'agit plus d'une rustine qu'une vrai implémentation de la généricité).
              Tout dépend si tu considères la généricité comme un point indispensable. Pour ma part, je la treouve utile, mais pas indispensable.
              Mais aussi la surcharge d'opérateur.
              Même remarque, même si cette fois je la trouve franchement superfétatoire.
              - covariance sur tous les parametres (but depuis le debut meme si on a trouve la solution théorique que récemment)
              - pas de types prédéfinis (tous les types, y compris ceux de net.nosica.lang sont entierement redéfinissable par l'utilisateur), ce qui explique pourquoi on a besoin de la distinction entre type primitifs/types references et surcharge d'operateur pour ne citer qu'eux.

              C'est pas un peu trop rock'n'roll comme objectif ?


              Sinon pour finir, sache que malheureusement je galere enormément à trouver du temps pour m'occuper de Nosica, alors le site oueb et la doc passe en dernier.
              Sache aussi que j'accepte volontiers la critique, mais la critique constructive. A ce titre ton deuxieme post est deja plus satisfaisant. Ceci dit il me semble que tu gagnerais a vraiment étudier le langage pour faire une critique plutôt que "parcourir" le site (critique que j'accepterai sans probleme, je ne cherche qu'a améliorer le langage)


              Si j'avais le temps, ça me tenterais, mais bien d'autres projets me tentent également, alors ...
              • [^] # Re: Je prefere Netbeans.

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

                il n'y a pas de pourquoi ... juste des comments
                OK, je vais formuler autrement :
                - syntaxe simple pour la lisibilite/maintenance du code
                - syntaxe que je trouve manquer a Java, parceque sinon il y a des pattern qui ne sont pas implementables et reutilisables (ex : la factory qu'il faut reimplementer from scratch en Java)
                - covariance sur tous les parametres parce que ca permet de rendre le langage plus sur en limitant les cast, parce que ca permet d'implementer du double dispatch sans passer par un visiteur, donc plus efficace, plus lisible, plus sur et plus maintenable ...
                - pas de type predefinis car il arrive qu'on ait besoin de modifier l'interface d'un type simple. Or souvent ce type est dans le compilo, donc read-only. Pas en Nosica. Et je te rassure ca marche plutot bien sans etre rock and roll : ca permet au contraire beaucoup de souplesse. Actuellement les seuls types vraiment codes en dur dans Nosica sont : Object, None, et Array.

                La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible
                Tout a fait d'accord avec toi. Il faut donc que je fasse une passe sur la doc pour rajouter le pourquoi de chaque feature. Deja, est ce que mon blob precedent te convient ?

                Pour info la surcharge sur le type retour marche tres tres bien. Une ancienne version la gerait tres bien. Malheureusement ca avait comme (mauvaises) consequences :
                - complexification du code du compilo (je pense que 30% du code du typechecker lui etait dedie)
                - reporting d'erreur illisible : presentation de toutes les branches d'executions possible en disant : desole pas de match, ou desole trop de match.
                - comprehension parfois difficile pour le programmeur : pas quel chemin se fait l'execution de f().g().h() ?

                Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.
                D'accord avec toi sur certains cas. Mon experience a moi me dit que ce n'est pas la majorite des cas. La solution de prendre des parametres en E/S alors que le parametre est vraiment en sortie est bancale. (necessite de doc, pas de check par le compilo du bon usage de la methode). Voir la thread http://www.nosica.net/forum/viewtopic.php?t=58&start=15(...) Tu verras qu'au départ j'étais contre cette feature. Et finalement ca le fait bien.
    • [^] # Re: Je prefere Netbeans.

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

      Juste pour rectifer :
      http://www.netbeans.org(...)
  • # Re: Eclipse compilé en natif.

    Posté par . Évalué à 2.

    en espérant que cette version native soit plus rapide (enfin) que la version java windows...
    • [^] # Re: Eclipse compilé en natif.

      Posté par . Évalué à 1.

      Eclipse devient souple d'utilisation a partir de la config P3 600 + 512Mo de RAM. Je n'ai jamais eu de reels problemes de performances sur des machines de ce type (sous Windows).
      • [^] # Re: Eclipse compilé en natif.

        Posté par . Évalué à 2.

        Eclipse devient souple d'utilisation [...] (sous Windows)

        Héhé je vois que monsieur aime bien mettre le doigt où ça fait mal. C'est effectivement la clé du problème : les JVM sous Linux sont à des années lumière en dessous des JVM sous Windows.
      • [^] # Re: Eclipse compilé en natif.

        Posté par . Évalué à 1.

        sous linux, meme avec 768Mo de RAM et 2Ghz, dsl mais j'ai du lag ds l'interface (principalement l'autocompletion/autocompletement), et ds l'affichage des fenetres...
        bon c'est un portable aussi, mais qd meme !!
      • [^] # Re: Eclipse compilé en natif.

        Posté par . Évalué à -1.

        c/c++, perl , ... avec emacs et ses tonnes de modules dans un banal environnement X ca demande pour etre (tres) confortable a peine un P200 et 128Mo de ram .

        Sur windows , un PPro 200 et 128Mo de ram c'etait absolument impec en 1996 pour faire du dev tres intensif sur VC++.

        Ce que demande java, c'est vraiment du delire.

        ok ok je sors -> []
  • # Re: Eclipse compilé en natif.

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

    Et on pourrait pas faire la même chose avec le code java d'OpenOffice.org ?
    (java y est utilisé pour certains trucs, comme l'aide, l'OLE, etc.)
    • [^] # Re: Eclipse compilé en natif.

      Posté par . Évalué à 1.

      Ca pourrait t'intéresser:
      http://www.planamesa.com/neojava/fr/(...)

      Même si de toute façon, c'est une abérration que de vouloir porter une horreur comme OpenOffice sous Aqua (ou OPENSTEP/GNUstep)
    • [^] # Re: Eclipse compilé en natif.

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

      si tu suis un peu les ml de gcj, y a des gens de rh et deb qui
      travaille dessus en essayer de compiler le code java avec gcj et l'utilisation de gij comme jvm, voire pour certain la compilation native gcj, mais le problème viens de quelques parties AWT dans le code et de certaines classes "sun" qui ne compile pas sous gcj
  • # Re: Eclipse compilé en natif.

    Posté par . Évalué à 1.

    Qq1 sait si un code Java compilé peut permettre le passage de buffer overflow ?
    • [^] # Re: Eclipse compilé en natif.

      Posté par . Évalué à 2.

      Oups, dans mon poste précedent, il manque "en natif"

      Qq1 sait si un code Java compilé en natif peut permettre le passage de buffer overflow ?
      • [^] # Re: Eclipse compilé en natif.

        Posté par . Évalué à 4.

        Qq1 sait si un code Java compilé en natif peut permettre le passage de buffer overflow ?

        Je ne pense pas.
        Pour que le programme compilé marche correctement, il faut qu'il ait le même comportement que sous la JVM, et il doit reproduire les tests effectués par la JVM quand elle manipule des chaînes de caractères (les Strings). Je fais court mais je pense que c'est à peu près clair comme explication :-)
        • [^] # Re: Eclipse compilé en natif.

          Posté par . Évalué à 4.

          le truc, c'est qu'en general tu commences par mettre une option du genre --no-boundary-check .... et hop, la possibilité de buffer overflow revient....
          • [^] # Re: Eclipse compilé en natif.

            Posté par . Évalué à 1.

            C'est vrai mais la vérification des bornes étant dans la spec de la JVM il serait logique que gcj ignore cette option. Ceci-dit sur ma version gcj (3.2) --no-boundary-check n'est pas une option reconnue.
  • # hum

    Posté par . Évalué à 5.

    Je ne comprends pas tout, et en particulier je croyais que du monde travaillait dur sur des implémentations libres de java. Du coup j'ai pensé un instant que c'était pour des raisons de performance mais en naviguant un peu je suis tombé sur des trucs comme ça:
    " It is currently a bit slow (you will need a fast processor, 1Ghz+ recommended) and needs much memory (256MB recommended). And not everything will work yet (it sometimes hangs)" [ http://www.klomp.org/mark/gij_eclipse/index.html(...) ]
    Je ne maitrise pas bien l'anglais mais il me semble bien qu'il dit que ça va un peu lentement et que tout marche pas.
    Si la lumiére pouvait descendre sur moi !
    • [^] # Re: hum

      Posté par . Évalué à 2.

      tu as bien compris., mais le compilateur est encore en développent donc c'est normal qu'il ne soit pas encore optimisé
      • [^] # Re: hum

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

        Sa va quand-même plus vite qu'avec une jvm j'espère ?
        • [^] # Re: hum

          Posté par . Évalué à 5.

          Tout dépend des options de la jvm ! Si la jvm tourne avec le just-in-time compiler lancé alors le programme tournera beaucoup plus vite que d'habitude dés le deuxième lancement. Le just-in-time fait comme son nom l'indique une compilation native de certaines portions du bytecode et donc dés que c'est fait ça va assez vite. Quand j'ai testé ça pouvait rivaliser avec des exécutables pas trop optimisé genre delphi ou kylix.
          Bien sur ça vaut pas un .c compilé avec gcc -o2 puissance 32 mais quand même c'est trés suffisant dans la plupart des cas !
          • [^] # Re: hum

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

            Faudrait voir à pas trop insulter les gens de chez Borland qui développent des compilateurs depuis plus de 20 ans. Dire que les exécutables produits par Delphi ou Kylix ne sont pas optimisés, c'est de la désinformation pure et simple.
            Un executable compilé avec Delphi doit facilement rivaliser avec GCC et même le surpasser dans certaines conditions.
        • [^] # Re: hum

          Posté par . Évalué à 4.

          ça va quand même plus vite qu'avec une JVM j'espère ?

          Une JVM n'est pas forcément lente, il ne faut pas confondre la relative lenteur de Swing avec la lenteur supposée de Java. Pour des applications de calcul numérique, Java n'est sans doute pas recommandé, mais pour faire de la base de données (par exemple) ça marche pas mal du tout. Il ne faut pas oublier les techniques de "compilation juste à temps" et autres astuces utilisées par les JVM pour obtenir de bonnes performances. En théorie une JVM peut faire presque mieux que du code compilé statiquement, grâce à l'analyse dynamique (en cours de fonctionnement).
          • [^] # Re: hum

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

            Une JVM n'est pas forcément lente, il ne faut pas confondre la relative lenteur de Swing avec la lenteur supposée de Java.
            Tout à fait. Swing est effectivement une API d'une lenteur effarante, mais il faut comprendre pourquoi. Afin de faire portable, Sun a en effet décidé de créer une deuxième boucle d'événements UI, de manière à être totallement indépendant de l'OS. Du coup, ça bouffe du temps de clacul à tous les étages.


            Pour des applications de calcul numérique, Java n'est sans doute pas recommandé,
            Pourquoi ?
            Dans ma première boîte (spécialisée en RN et stats), j'ai fait un test un jour comparant une lib Java de matrices et la lib lopcale (écrite en C, donc supposée optimisée), et Java y était deux fois plus rapide.

            mais pour faire de la base de données (par exemple) ça marche pas mal du tout.
            Pour faire de l'embarqué, du réseau, du multiplateforme facile, ... et tout un tas d'autres choses, Java est très bien, et comme tu le dis si bien, largement suffisant.
            • [^] # Re: hum

              Posté par . Évalué à 1.

              hum... la lib local devait être codé avec les pieds non ? Tu as testé avec blitz+ ou la lib scientifique gnu ?

              "La première sécurité est la liberté"

              • [^] # Re: hum

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

                Oui, elle était codée très simplement (et surtout, les tests de performances se faisaient "à l'oeil" et non en présence d'un profiler).
              • [^] # Re: hum

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

                la lib scientifique gnu

                si c'est la GSL dont tu parles, elle n'a pas pour but d'être spécialement rapide mais d'être protable et d'avoir un code clair. Il n'y a pratiquement pas d'optimisation plateforme-spécifiques, seulement de bons algorithmes.
            • [^] # Re: hum

              Posté par . Évalué à 0.

              > Swing est effectivement une API d'une lenteur effarante

              Sans compter qu'il n'est pas aidé par la lenteur de XWindows (par rapport au GDI de Fenêtres(tm).

              • [^] # Re: hum

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

                Mouarf, c'est a cause de X que swing est lent, bien sur. Heureusement que X a tant de défaut pour encore pouvoir lui en mettre d'autre sur le dos.
    • [^] # Re: hum

      Posté par . Évalué à 10.

      Tu te demandes donc pq "en natif" ne va pas plus vite qu'avec une JVM?

      La réponse à cette question est complexe, je vais cependant tenter de te donner quelques points de réponses:
      - une JVM, de nos jours, n'est plus si "VM" que ça, c'est surtout un bon JITter, autrement dit ton bytecode devient du code natif, qui n'est donc pas si lent à exécuter que cela. (c'est du .NET, mais Quake2.NET tourne relativement bien, quelques pourcent de diff avec le code natif... optimisé en asm).
      - Java (et .NET et tout les beaux langages maheureusement sous utilisé tel que python et ruby) apporte quelques choses que les langages natifs n'ont pratiquement pas: l'introspection. Et eclipse semble en abuser, il faut donc mimer ce comportement en natif, ce qui revient pratiquement à faire une JVM.
      - Une version native se base sur les composant natif existant, il faut donc arriver à mapper les classes java aux api native, ce qui n'est pas facile. Et tu te retrouves avec le problème suivant: java utilise swt qui utilise gtk, en natif, tu dois faire le natif qui utilise l'émulation de swt qui utilise gtk... tu as donc des étapes supplémentaire à l'utilisation directe de gtk. Si tu compares une app java "compilé en natif" tu auras donc des perfs moins bonnes qu'une app native depuis le début.

      Rajoute à cela que le tout n'est pas encore optimisé... et tu devrais finir par te dire que c'est pas si étonnant que ça ;)
      • [^] # Re: hum

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

        Il me semble que l'un des principaux interets de compiler Java c'est que cela occupe moins de memoire et demarre plus vite car il n'y a pas de JVM a lancer qui bouffe plein de RAM.
      • [^] # Re: hum

        Posté par . Évalué à 2.

        Donc ma question reste presqu'entière : pourquoi un compilateur java plutôt qu'une JVM libre trés performante dans la mesure ou rendre un code natif réellement performant semble extrémement délicat ?
        • [^] # Re: hum

          Posté par . Évalué à 1.

          Pour profiter de toutes les architectures supportées par GCC ? (J'en sais rien mais je suppose)
        • [^] # Re: hum

          Posté par . Évalué à 2.

          À mon avis grâce à gcc, il est nettement plus simple de faire un compilateur de code Java qu'une JVM qui speed sa race ... euh qu'une JVM très performante (ouf). Si "transcription" du bytecode en assembleur peut sembler identique entre un compilateur "normal" et un compilateur JIT (cJIT) il y a malgré tout quelques différences pas négligeables :
          • un cJIT doit être rapide car la compilation de bytecode entre dans le temps d'exécution ; au démarrage mais aussi durant l'exécution si une classe est chargée à la volée il est hors de question d'attendre 2 minutes que le compilateur ait terminé de la traiter ;
          • un cJIT doit être capable d'optimiser le code en prennant en compte des paramètres qui ne sont disponibles qu'à l'exécution ;
          • la JVM doit pouvoir faire des stats sur l'utilisation des portions de code et demander à au compilateur de recompiler une partie de code avec une optimisation plus poussée.
          C'est donc quelque chose de totalement différent de créer un compilateur pour un nouveau langage en s'appuyant sur Gcc.
          • [^] # Re: hum

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

            > un compilateur pour un nouveau langage en s'appuyant sur gcc.

            C'est surtout ca je pense. Ils ne doivent pas tout reinventer puisque gcc est la base. gcc compile deja du C, C++, Objective-C, Fortran et ADA. Sachant que Java est tres proche de C++ et meme plus simple comme language (quoique avec l'introduction des templates dans Java), ils ont donc une base qui fonctionnent bien, maintenu, deja optimise... maintenant ils doivent refaire toutes les libs Java ce qui n'est pas une mince affaire (et d'ailleurs Mono ils sont pas pres d'y arriver vu le travail que ca demande).

            D'ailleurs il me semble que gcj est bien plus populaire (et plus avance ?) que les autres JVM libre, non ?
        • [^] # Re: hum

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

          gcj c'est le compilo, gij la jvm donc pas de prob les deux sont en dev
      • [^] # Re: hum

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

        « [...] apporte quelques choses que les langages natifs n'ont pratiquement pas: l'introspection. »

        L'introspection ça coûte rien en temps à l'execution (que de la place et pas beaucoup en plus) à compiler en natif[1]. Ce qui coute c'est la réflexivité (qu'il me semble que Java n'a pas de toute façon[2] mais que ruby et python ont).
        La différence entre les deux c'est que le premier permet de visiter les structures et données du langages à l'exécution (« ya telle classe avec telle méthode de telle nom », c'est bien pour faire des composants) et le second permet de modifier les structures et donnés du langages à l'exécution (« tiens, je vais creer une nouvelle classe, tiens maintenant cette méthode ne me plait plus, je vais la changer... » c'est bien pour faire des tas de trucs, tres puissant mais c'est galère à compiler efficacement)


        [1] Il me semble que SmartEiffel la propose (dans la dernière release ou béta, à vérifier)
        [2] Je devrais me tenir plus au courant, j'ai honte :)
        • [^] # Re: hum

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

          Ce qui coute c'est la réflexivité (qu'il me semble que Java n'a pas de toute façon[2] mais que ruby et python ont).

          Pardon ?

          et java.lang.reflect ?

          C'est même une fonctionnalité primordiale de java... Comment ferait un application server java sans ça ...?
          • [^] # Re: hum

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

            Je me suis mal exprimé alors : ce que Java apelle « reflect » est de l'introspection, pas de la reflexivité dans le sens entier du terme ("reflect" c'est limite du marketing dans ce cas là).

            Pour avoir de la reflexivité il faut pouvoir agir sur les objets fournis par java.lang.reflect mais aussi les modifier. C'est-à-dire faire des choses que permettent OpenJava par exemple mais à l'exécution pas à la compilation.

            La dernière fois que j'ai touché à Java on ne pouvait pas modifier la structures des objets du langages comme ajouter une nouvelle méthode à une classe, creer une nouvelle classe, changer l'arbre d'héritage, etc.
            C'est pour ça que je disais que Java n'a pas de reflexivité, contrairement à Ruby (qui en a pas mal) et sans doute Python.

            Je résume : accès en "read-only" => introspection, accès en "read/write" => reflexivité.

            Bon, si maintenant Java possède un peu de rexlexivité, je ferais amende honorable et j'irai propager la bonne nouvelle.
            • [^] # Re: hum

              Posté par . Évalué à 2.

              Bon, si maintenant Java possède un peu de rexlexivité, je ferais amende honorable et j'irai propager la bonne nouvelle.

              Et tu tu fouettera avec des ronces et des orties en place de grève ? Bon parce que si c'est le cas il y a un truc sympa qu'il s'appele BCEL[1] qui permet, à lexécution de manipuler le byte-code. En ce qui me concerne je ne l'ai utilisé que pour générer de nouvelles classes à la volée mais il me semble que ça peut faire tout ce qui est dans la définition de réfléxivité que tu donnes. C'est vrai que c'est une bibliothèque de bas niveau mais ce serait assez facile d'écrire un wrapper autour histoire de rendre son utilisation plus humaine. Comme je le disais je l'ai utilisé pour créer des classes à la volée et d'un point de vue perf c'est complètement comparable à des classes écritent à la mimine et compilées "normalement".

              Bon j'admet que c'est capillotracté alors je veux bien que tu n'utilise que les orties.

              [1] Byte Code Engineering Library : http://jakarta.apache.org/bcel/index.html(...)
              • [^] # Re: hum

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

                Oui mais je parlais de Java en version de base parce que sinon pas besoin de généritité dans la prochaine version puisq'il y a Pizza et euh... bon... que les orties alors, hein ?

                Sinon il y a aussi Javassist qui est bien a ce qu'on m'a dit. Ça fait de la reflexivité.
                http://www.csg.is.titech.ac.jp/~chiba/javassist/(...)

                Mais c'est solutions sont du niveau de l'emplâtre sur la jambe de bois, amha, dans le sens où on est obligé de passer par des techniques souvent lourdingues pour arriver à nos fins. Le but d'un langage de prog est de pouvoir synthetiser certains concepts afin de les rendres plus simple d'emplois car plus naturelles pas de focer les gens à faire des contortions pour être utilisables[1].

                De même qu'il est possible de faire de l'objet en C, assembleur et éventuellement en brainfuck, il est tout à fait possible de faire de la reflexivité en Java et p'tet aussi en GOTO++ mais je terminerais cette phrase mal partie et que j'ai pas mangé encore en disant que si ton langage est pas capable de faire quelque chose de simplement, change de langage pour faire cette chose[3], puis reviens vers ton premier langage si celui-ci est meilleur pour autre chose.

                [1] Bien que on rencontre parfois des gens qui pensent que un bon programmeur est celui qui est maso vis-à-vis des langages[2]
                [2] Bon, aujourd'hui j'ai décidé de pas parler de Perl ou de C++ donc je dirais rien promis :)
                [3] En fait non, je décourage quiquonque à avoir çe genre de pratique car à terme cela force à connaitre plein de langages et ainsi se rendre compte que non seulement ils sont tous effroyablement mauvais mais qu'en plus ceux qui sont les moins pires sont très peux utilisés. Et après on devient aigri... Bah, les gens fanatiques de leurs langages sont sans doute plus à plaindre mais ils ont l'aventage de ne pas s'en rendre compte.
                • [^] # Re: hum

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

                  Bon la manipulation de byte code est possible en java... créer des stub dynamique, etc... JDO utilise cette fonctionnalité pour ajouter à la volée les méthodes de persistence... un obfusctor utilise aussi cette technique...

                  Donc c'est possible et utilisé...

                  Maintenant je connais pas ruby... donc... je ===>[]

                  Mais si je te comprends bien, une bibliothèque ajoutée à un langage ne compte pas... même écrite entièrement avec ce langage ?

                  Pour moi java, c'est le langage, la spec d'une jvm... puis au dessus, y a les bibliothèques standard ou non...

Suivre le flux des commentaires

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