Java, c'est un langage a VM, meme si la spec du langage en soit est techniquement decorrelle de la vm, mais je n'arrive pas a imaginer un seul interet a implementer le langage en dehors de la vm. De meme, j'ai jamais compris a quoi pouvait bien servir gcj (bon, ok, jvm pas libre tout ca, mais c'est plus le cas).
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
Tout dépend du point de vue. Il y a de très grandes quantités de code java disponible que tu n'as pas forcément envie de réécrire, mais en même temps tu en as peut-être rien à foutre de la portabilitée car tu es sur une plateforme figée : ton desktop par exemple.
Dans ce cas, avec gcj tu profites du code tout en ayant les avantages d'un code directement natif.
Il faut bien voir que la portabilité c'est un concept qui existe au moment de la difusion, mais beaucoup moins dans de nombreux cas d'utilisation. Quand on écrit du code on veut qu'il marche chez le plus de personnes possibles, quand on l'utilise on veut qu'il marche chez soit.
Une VM permet les deux mais un compilateur tel que gcj permet uniquement le deuxième. L'avantage c'est qu'il n'y a pas à attendre que la VM s charge ou que le JIT produise du code.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
Je pense que les créateurs de Ch ne soient pas d'accord avec toi, et leur bizness dure depuis un bout de temps donc leur clients ne doivent pas être d'accord non plus.
L'avantage de faire tourner du C sur une machine virtuelle c'est que tu éxectues le code dans un environement sécuriser et tu peut inclure l'interpreteur dans un autre programme.
Et comme pour au dessus, du dispose d'une quantité faramineuse de code déjà écrit.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
Et pourtant si, ça aurait un sens. Le programme gagne les avantages de l'environement managé de .net ou de la jvm, et des facilitées de comunications inter langages. Cela permet aussi de cibler des plateformes ou seul ce genre de code est accepté.
Sur android par exemple tu ne peut éxectuer que du code java, ça pourrait être cool d'avoir autre chose. L'exemple est mal choisit puisque c'est une JVM modfié et qu'ils ont sortit un NDK, mais l'idée est là.
Il faut bien voir que natif ou VM c'est des techniques complémentaires qui ont chacune leurs avantages et inconvénients, et à part certaines construction particulière il est généralement possible de ciber l'un ou l'autre indiférament. Disposer des deux est même un avantage pour un langage.
[^] # Re: Surprise
Posté par beagf . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
Tout dépend du point de vue. Il y a de très grandes quantités de code java disponible que tu n'as pas forcément envie de réécrire, mais en même temps tu en as peut-être rien à foutre de la portabilitée car tu es sur une plateforme figée : ton desktop par exemple.
Dans ce cas, avec gcj tu profites du code tout en ayant les avantages d'un code directement natif.
Il faut bien voir que la portabilité c'est un concept qui existe au moment de la difusion, mais beaucoup moins dans de nombreux cas d'utilisation. Quand on écrit du code on veut qu'il marche chez le plus de personnes possibles, quand on l'utilise on veut qu'il marche chez soit.
Une VM permet les deux mais un compilateur tel que gcj permet uniquement le deuxième. L'avantage c'est qu'il n'y a pas à attendre que la VM s charge ou que le JIT produise du code.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
Je pense que les créateurs de Ch ne soient pas d'accord avec toi, et leur bizness dure depuis un bout de temps donc leur clients ne doivent pas être d'accord non plus.
L'avantage de faire tourner du C sur une machine virtuelle c'est que tu éxectues le code dans un environement sécuriser et tu peut inclure l'interpreteur dans un autre programme.
Et comme pour au dessus, du dispose d'une quantité faramineuse de code déjà écrit.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
Et pourtant si, ça aurait un sens. Le programme gagne les avantages de l'environement managé de .net ou de la jvm, et des facilitées de comunications inter langages. Cela permet aussi de cibler des plateformes ou seul ce genre de code est accepté.
Sur android par exemple tu ne peut éxectuer que du code java, ça pourrait être cool d'avoir autre chose. L'exemple est mal choisit puisque c'est une JVM modfié et qu'ils ont sortit un NDK, mais l'idée est là.
Il faut bien voir que natif ou VM c'est des techniques complémentaires qui ont chacune leurs avantages et inconvénients, et à part certaines construction particulière il est généralement possible de ciber l'un ou l'autre indiférament. Disposer des deux est même un avantage pour un langage.
[1] http://www.softintegration.com/products/