Master-dik, je t'aime beaucoup quand tu fais des blagues lourdes, mais il y a des limites.
Il existe au moins deux langages très intéressants qui compilent pour la JVM, à savoir Python et Eiffel. Donc, bien sûr, le lien donné plus haut contient aussi des choses plus anecdotique, mais franchement entre VB sur .Net et Eiffel sur JVM, j'ai un petit faible pour la deuxième solution...
Sinon, effectivement la JVM a été pensée pour Java, mais la machine virtuelle .Net (CLR) a aussi été conçue avec certains biais. Par exemple le CLR a été conçu presque uniquement pour le JIT contrairement à la JVM. Sur le site http://www.citi.qut.edu.au/research/plas/projects/cp_files/Componen(...) il a d'ailleurs une comparaison assez claire des deux architectures. On constate par exemple que la vérification de code pour CLR demande nécessairement une partie runtime, ce qui n'est pas le cas pour la JVM (d'où une perte de performance pour le premier). Par contre CLR autorise le passage de paramètre par adresse pour les types fondamentaux, ce qui permet une implantation efficace des langages qui autorisent ce genre de construction, contrairement à la JVM. Un autre aspect est que l'interprétation (sans JIT) du code CLR est souvent plus lent que pour la JVM, toujours pour des raisons d'architecture.
Bref, CLR a été effectivement pensé pour supporter divers langages, mais en pratique il y a une seule différence majeure avec la JVM : la possibilité d'implanter efficacement le passage par référence des types fondamentaux. Franchement, on ne va pas en faire tout un fromage...
[^] # Re: Plein de langage pour la JVM
Posté par boubou . En réponse à la dépêche Benchmark J2EE vs dotNET. Évalué à 1.
Il existe au moins deux langages très intéressants qui compilent pour la JVM, à savoir Python et Eiffel. Donc, bien sûr, le lien donné plus haut contient aussi des choses plus anecdotique, mais franchement entre VB sur .Net et Eiffel sur JVM, j'ai un petit faible pour la deuxième solution...
Sinon, effectivement la JVM a été pensée pour Java, mais la machine virtuelle .Net (CLR) a aussi été conçue avec certains biais. Par exemple le CLR a été conçu presque uniquement pour le JIT contrairement à la JVM. Sur le site http://www.citi.qut.edu.au/research/plas/projects/cp_files/Componen(...) il a d'ailleurs une comparaison assez claire des deux architectures. On constate par exemple que la vérification de code pour CLR demande nécessairement une partie runtime, ce qui n'est pas le cas pour la JVM (d'où une perte de performance pour le premier). Par contre CLR autorise le passage de paramètre par adresse pour les types fondamentaux, ce qui permet une implantation efficace des langages qui autorisent ce genre de construction, contrairement à la JVM. Un autre aspect est que l'interprétation (sans JIT) du code CLR est souvent plus lent que pour la JVM, toujours pour des raisons d'architecture.
Bref, CLR a été effectivement pensé pour supporter divers langages, mais en pratique il y a une seule différence majeure avec la JVM : la possibilité d'implanter efficacement le passage par référence des types fondamentaux. Franchement, on ne va pas en faire tout un fromage...