Svp, quelle différence entre le byte code produit par le compilateur java et le Microsoft Intermediate language (MSIL) en ce qui concerne la dépendance du matériel et de la plateforme d'exécution.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Différence entre le byte-code de Java et MSIL
Svp, quelle différence entre le byte code produit par le compilateur java et le Microsoft Intermediate language (MSIL) en ce qui concerne la dépendance du matériel et de la plateforme d'exécution.
Les deux machines virtuelles n'étant pas les mêmes, je suis pas sur qu'on puisse trop comparer
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
Je m'explique ..
alors pourquoi les environnements d'exécution de .NET se limitent à Windows alors que Java est portable sur d'autres environnements (Linux..).Net et Java compilent leur code source dans un langage indépendant de tout système et de tout hardware
Car Microsoft n'a jamais pris le temps ou vu l'interet de développer une machine virtuelle executant le MSIL.Envoyé par medamin27
alors pourquoi les environnements d'exécution de .NET se limitent à Windows alors que Java est portable sur d'autres environnements (Linux..)
Faut dire que l'interoperabilité ca coûte cher et ca rapporte pas forcément. De toute facon, .NET n'est qu'une surcouche des api win32. Et Microsoft n'étant pas maitre des autres api, il serait difficile pour eux de s'y brancher. De base, .Net propose plus de fonctions couplés étroitement à Windows que Java.
Retrouvez moi sur :
Il faut quand même noter qu'il y'a le projet mono qui avait été lancé dans le but de l'interop et le .net 2.0 a déjà été porté sur les plateformes linux, je n'ai jamais testé.
Je n'ai toujours pas réussi à comprendre l'utilité, pour Microsoft, de fournir un système avec une couche intermédiaire de byte-code. Ce framework n'aurait-il vraiment pas pu être développé et fourni en natif directement ?
D'abord il faut différencier la CLI (common language infrastructure) et le CLR (common language runtime).
La CLI comporte toutes les biblios et est très liée à Windows (il suffit de penser aux API Windows Forms) ce qui a assuré son succès dans le développement des applis bureau (look'n' feel natif) mais la rend difficile à porter sur d'autres systèmes d'exploitation que Windows sans violer de brevets (Novell a obtenu à ce titre des garanties pour Mono).
La CLR est l'environnement d'exécution lui-même ("machine virtuelle" même si MS n'utilise pas ce terme: sous le capot les choses sont différentes de Java) et il existe bien sur plusieurs processeurs : principalement x86 et ARM (smartphones: dotnet est la plateforme de référence pour Windows mobile). Il a aussi été porté par MS sur je ne sais plus quelle plateforme pour serveurs.
A la base, ce fut surtout un outil marketing en l'absence de volonté de MS. Mais Novell fournit aujourd'hui des portages pour divers Unix, dont notamment Android.
Mentionnons un dernier intérêt : fournir un code vérifiable, contrairement au code x86. Voir leurs recherches sur Singularity. On pourrait aussi ajouter la possibilité d'optimiser le code au chargement en fonction des sous-jeux d'instructions présents (songe à MMX et SSE) en plus du socle x86. Mais je ne crois pas que cette dernière possibilité soit utilisée.
J'ai pas tilté à l'époque mais il n'y a pas que sur Windows que .Net existe. Sur Linux, l'implémentation n'est pas de Microsoft c'est Mono. Mais il y'a aussi les systèmes embarqués (Compact Framework, Windows Mobile, Windows Phone 7) et il y'a la Xbox.
De plus l'interet d'un bytecode est que tout le monde peut écrire un compilateur vers ce bytecode (d'ou l'utilisation de C#, VB.Net, Python, Ruby pour faire du .Net)
Retrouvez moi sur :
Plus précisément, pour l'OP : dans la mesure où le CLR définit un système flexible de types, plusieurs langages de nature très différente peuvent s'appuyer sur ce socle commun et dialoguer ensemble (possiblement d'utiliser naturellement en C# une biblio écrite en ironpython par ex, comme si elle avait elle-même été écrite en C#).
Sinon bien vu, j'avais carrément oublié ce point !
Répondre avec citation
Partager