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.
Aller plus loin
- L'annonce (4 clics)
- Les RPM pour la Red Hat Entrerise (2 clics)
- D'autres packages compilés avec GCJ (1 clic)
- Eclipse (1 clic)
- gcj (3 clics)
# Re: Eclipse compilé en natif.
Posté par analogue o/ (site web personnel) . Évalué à 1.
http://www.eclipse-game.com/htm/eos.htm(...)
[^] # Re: Eclipse compilé en natif.
Posté par Gruik Man . Évalué à -1.
[^] # Re: Eclipse compilé en natif.
Posté par Lafrite . Évalué à 0.
[^] # Re: Eclipse compilé en natif.
Posté par Mathias Bavay (site web personnel) . Évalué à -1.
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 Maillequeule . Évalué à 10.
Qu'est ce qui assombrit le soleil ? :)
Eclipse of sun, ou comment récupérer un peu Java :)
M
[^] # Re: Eclipse
Posté par dinomasque . Évalué à 0.
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 20 ans !
[^] # Re: Eclipse
Posté par poil oq . Évalué à 3.
[^] # Re: Eclipse
Posté par bmc . Évalué à 2.
(ATTENTION: ce message contient une bonne dose d'ironie et dénigre sans vergogne les produits HP)
[^] # Re: Eclipse
Posté par Jean Michel Delafleur . Évalué à -2.
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 JSL . Évalué à 3.
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 Mes Zigues . Évalué à 0.
C'était la minute astronomique.
[^] # Re: Eclipse
Posté par Buf (Mastodon) . Évalué à 3.
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.
[^] # Re: Eclipse
Posté par Alain Tésio . Évalué à 2.
lunaires sur 5000 ans:
http://sunearth.gsfc.nasa.gov/eclipse/LEcat/LEcatalog.html(...)
12186/5000=2.44/an
solaires sur 6000 ans:
http://sunearth.gsfc.nasa.gov/eclipse/SEcat/SEcatalog.html(...)
14623/6000=2.38/an
Moi aussi je peux donner une explication bidon pour faire le malin : c'est parce que le diamètre apparent moyen de la lune est plus gros que celui du soleil donc elle gagne.
# Je prefere Netbeans.
Posté par Dalton joe . Évalué à 3.
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 Larry Cow . Évalué à 10.
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 Nicolas Delsaux (site web personnel) . Évalué à 3.
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 Epsos . Évalué à 1.
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 Nicolas Delsaux (site web personnel) . Évalué à 3.
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 Epsos . Évalué à 5.
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 Nicolas Delsaux (site web personnel) . Évalué à 2.
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 Epsos . Évalué à 3.
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 Nicolas Delsaux (site web personnel) . Évalué à 2.
Et effectivement, il faut surtout faire une bonne passe sur la doc pour obtenir la clarté nécessaire.
[^] # Re: Je prefere Netbeans.
Posté par Epsos . Évalué à 1.
La version Francaise arrive bientot ...
Qu'est ce que tu en penses ?
[^] # Re: Je prefere Netbeans.
Posté par Epsos . Évalué à 1.
http://www.nosica.net/user_zone.php?id=FR_Why+Nosica(...)
[^] # Re: Je prefere Netbeans.
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
[^] # Re: Je prefere Netbeans.
Posté par spell (site web personnel) . Évalué à 1.
http://www.netbeans.org(...)
# Re: Eclipse compilé en natif.
Posté par aurel . Évalué à 2.
[^] # Re: Eclipse compilé en natif.
Posté par Rossel Olivier . Évalué à 1.
[^] # Re: Eclipse compilé en natif.
Posté par gabuzo . Évalué à 2.
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 aurel . Évalué à 1.
bon c'est un portable aussi, mais qd meme !!
[^] # Re: Eclipse compilé en natif.
Posté par kesako . Évalué à -1.
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 ccomb (site web personnel) . Évalué à 7.
(java y est utilisé pour certains trucs, comme l'aide, l'OLE, etc.)
[^] # Re: Eclipse compilé en natif.
Posté par Merlin Lenchanteur . Évalué à 1.
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 Bapt (site web personnel) . Évalué à 1.
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 syj . Évalué à 1.
[^] # Re: Eclipse compilé en natif.
Posté par syj . Évalué à 2.
Qq1 sait si un code Java compilé en natif peut permettre le passage de buffer overflow ?
[^] # Re: Eclipse compilé en natif.
Posté par Olivier Jeannet . Évalué à 4.
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 Anthony . Évalué à 4.
[^] # Re: Eclipse compilé en natif.
Posté par gabuzo . Évalué à 1.
# hum
Posté par capparis . Évalué à 5.
" 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 Staz . Évalué à 2.
[^] # Re: hum
Posté par gndl (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par Eric Boulat . Évalué à 5.
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 Delannoy Maxence (site web personnel) . Évalué à 1.
Un executable compilé avec Delphi doit facilement rivaliser avec GCC et même le surpasser dans certaines conditions.
[^] # Re: hum
Posté par Olivier Jeannet . Évalué à 4.
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 Nicolas Delsaux (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: hum
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par Vivi (site web personnel) . Évalué à 1.
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 Laurent PELLISSIER . Évalué à 0.
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 Pierre Tramo (site web personnel) . Évalué à 2.
[^] # Re: hum
Posté par tene . Évalué à 10.
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 tanguy_k (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par Anthony . Évalué à 5.
http://www.alphaworks.ibm.com/tech/JAX(...)
mais bon, est ce que toute l'api de awt/swing est utilisable avec gcj ?
est ce qu'on peut interpreter du bytecode produit avec sun jdk 1.4 avec l'extension pour les templates (1.5)?
est-ce qu'un bench cni+gcj vs jni+gcj vs sdk+jni existe quelque part ???
[^] # Re: hum
Posté par tanguy_k (site web personnel) . Évalué à 3.
[^] # Re: hum
Posté par capparis . Évalué à 2.
[^] # Re: hum
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: hum
Posté par gabuzo . Évalué à 2.
- 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 tanguy_k (site web personnel) . Évalué à 1.
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 Bapt (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par MrTout (site web personnel) . Évalué à 4.
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 allcolor (site web personnel) . Évalué à 3.
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 MrTout (site web personnel) . Évalué à 3.
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 gabuzo . Évalué à 2.
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 MrTout (site web personnel) . Évalué à 2.
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 allcolor (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.