Ben c'est pas la définition du geek moyen qui n'y connait rien en technique de compilation, mais c'est une définition qui me semble juste et que je ne suis pas seul à reprendre. La phrase que j'ai tiré de la page de la JVM montre que je ne suis pas seul derrière cette définition.
Et cette définition a l'avantage d'être cohérente : d'un côté la notion de "machine virtuelle" qui se raccroche bien à quelque chose qui n'existe pas, et de l'autre différentes technique d'implémentation qui montre qu'une VM n'est pas forcement synonyme de la présence d'un "lourd interpréteur lent comme une loutre".
Beaucoup de gens confonde peut-être runtime/interpréteur/compilateurJIT et VM, mais c'est pour moi un héritage du passé où effectivement les VM étaient implémentées comme de bêtes interpréteurs : l'utilisateur identifie alors la VM à l'exécutable chargé d'interpréter le bytecode.
Depuis les VM n'ont jamais été aussi présentes mais les techniques d'exécution ont largement évoluées, et oublier la définition qui fait abstraction de toute implémentation, c'est ignorer ces évolutions.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Et cette définition a l'avantage d'être cohérente : d'un côté la notion de "machine virtuelle" qui se raccroche bien à quelque chose qui n'existe pas, et de l'autre différentes technique d'implémentation qui montre qu'une VM n'est pas forcement synonyme de la présence d'un "lourd interpréteur lent comme une loutre".
Beaucoup de gens confonde peut-être runtime/interpréteur/compilateurJIT et VM, mais c'est pour moi un héritage du passé où effectivement les VM étaient implémentées comme de bêtes interpréteurs : l'utilisateur identifie alors la VM à l'exécutable chargé d'interpréter le bytecode.
Depuis les VM n'ont jamais été aussi présentes mais les techniques d'exécution ont largement évoluées, et oublier la définition qui fait abstraction de toute implémentation, c'est ignorer ces évolutions.