Qu'est-ce que la portabilité? Comment java est-il plus portable que les autres langues? [fermé]
Je me demande comment Java est plus portable que C, C++ et.NET et tout autre langage. J'ai lu plusieurs fois que java était portable en raison de l'interpréteur et de la JVM, mais la JVM cache simplement les différences architecturales dans le matériel, non? Nous aurions toujours besoin de différentes JVM pour différentes architectures de machines. Ce qui me manque ici? Donc, si quelqu'un écrit une couche d'abstraction pour C pour les architectures les plus courantes, disons le CVM, alors n'importe quel programme C s'exécutera sur ces architectures une fois CVM est installé, n'est-ce pas?
Quelle est exactement cette portabilité? Pouvez .NET être appelé portable?
11 answers
La portabilité n'est pas une chose en noir et blanc, oui ou non. La portabilité est la facilité avec laquelle je peux prendre un programme et l'exécuter sur toutes les plates-formes dont on se soucie.
Il y a quelques choses qui affectent cela. L'un est le langage lui-même. La spécification du langage Java laisse généralement beaucoup moins à "l'implémentation". Par exemple, "i = i++" n'est pas défini en C et C++, mais a une signification définie en Java. Plus concrètement, des types comme " int " ont une taille spécifique en Java (par exemple: int est toujours 32 bits), tandis qu'en C et C++ la taille varie en fonction de la plate-forme et du compilateur. Ces différences seules ne vous empêchent pas d'écrire du code portable en C et C++, mais vous devez être beaucoup plus diligent.
Un Autre est les bibliothèques. Java a un tas de bibliothèques C et C++ n'ont pas. Par exemple, les bibliothèques de threading, de mise en réseau et d'interface graphique. Des bibliothèques de ce type existent pour C et C++, mais elles ne font pas partie de la norme et les bibliothèques correspondantes sont disponibles peut varier considérablement d'une plateforme à l'autre.
Enfin, il y a toute la question de savoir si vous pouvez simplement prendre un exécutable et le déposer sur l'autre plate-forme et le faire fonctionner là-bas. Cela fonctionne généralement avec Java, en supposant qu'il existe une JVM pour la plate-forme cible. (et il y a des JVM pour beaucoup/la plupart des plates-formes qui intéressent les gens) Ce n'est généralement pas vrai avec C et C++. Vous allez généralement au moins besoin d'une recompilation, et cela suppose que vous avez déjà pris soin du deux points précédents.
Oui, si un "CVM" existait pour plusieurs plates-formes, cela rendrait C et C++ plus portables -- en quelque sorte. Vous auriez toujours besoin d'écrire votre code C soit de manière portable (par exemple: en supposant rien sur la taille d'un int autre que ce que dit la norme) ou vous écririez dans le CVM (en supposant qu'il a pris une décision uniforme pour toutes ces sortes de choses sur toutes les plates-formes cibles). Vous devrez également renoncer à l'utilisation de bibliothèques non standard (pas de mise en réseau, de threading ou GUI) ou écrivez aux bibliothèques CVM-spécifiques à ces fins. Donc, nous ne parlons pas vraiment de rendre C et C++ plus portables, mais un CVM-C/C++ spécial qui est portable.
Encore une fois, la portabilité n'est pas une chose en noir et blanc. Même avec Java, il peut toujours y avoir des incompatibilités. Les bibliothèques GUI (en particulier AWT) étaient notoires pour avoir un comportement incohérent, et tout ce qui implique des threads peut se comporter différemment si vous êtes bâclé. En général, cependant, c'est beaucoup plus facile prendre un programme Java non trivial écrit sur une plate-forme et l'exécuter sur une autre, c'est faire la même chose avec un programme écrit en C ou C++.
Comme d'autres l'ont déjà dit, la portabilité est un concept un peu flou. D'un certain point de vue, C est en fait plus portable que Java. C fait très peu d'hypothèses sur le matériel sous-jacent. Il ne suppose même pas qu'il y a 8 bits dans un octet, ou que les nombres négatifs doivent être représentés en utilisant le complément de deux. Théoriquement, tant que vous avez une machine basée sur Von Neumann et un compilateur, vous êtes bon pour aller avec C.
En fait, un " Hello world" programme écrit en C va travailler sur beaucoup plus de plates-formes qu'un programme "Hello world" écrit en Java. Vous pourriez probablement obtenir le même programme "hello world" pour fonctionner sur un PDP-11 et un iPhone.
Cependant, la réalité est que la plupart des programmes du monde réel font beaucoup plus que la sortie "Hello world". Java a la réputation d'être plus portable que C car dans la pratique, il faut beaucoup plus d'efforts pour porter des programmes C du monde réel sur différentes plates-formes que programmes Java du monde réel.
C'est parce que le langage C est vraiment ANSI-C, qui est un langage extrêmement général et simple. Il ne prend pas en charge la programmation réseau, le threading ou le développement d'interfaces graphiques. Par conséquent, dès que vous écrivez un programme qui inclut l'une de ces choses, vous devez vous rabattre sur une extension moins portable en C, comme Win32 ou POSIX ou autre.
Mais avec Java, la programmation réseau, le threading et les outils GUI sont définis par langue et intégré dans chaque implémentation de VM.
Cela dit, je pense que beaucoup de programmeurs sous-estiment aussi les progrès du C/C++ moderne en matière de portabilité ces jours-ci. POSIX va un long chemin vers la fourniture de threads multiplateformes, et en ce qui concerne C++, Boost fournit des bibliothèques de mise en réseau et de threading qui sont fondamentalement aussi portables que n'importe quoi en Java. Ces bibliothèques ont des bizarreries spécifiques à la plate-forme, mais Java aussi.
Essentiellement, Java s'appuie sur chaque plate-forme ayant une implémentation de machine virtuelle qui interprétera le code d'octet de manière prévisible, et C/C++ s'appuie sur des bibliothèques qui incorporent du code spécifique à la plate-forme en utilisant le préprocesseur (#ifdefs). Les deux stratégies permettent le threading multiplateforme, la mise en réseau et le développement d'interfaces graphiques. C'est simplement que Java a fait des progrès plus rapides que C/C++ en matière de portabilité. La spécification du langage Java avait threading, mise en réseau et le développement de l'interface graphique presque dès le premier jour, alors que le Boost la bibliothèque de mise en réseau n'est sortie que vers 2005, et ce n'est qu'en 2011 avec C++11 que le threading portable standard a été inclus dans C++.
Lorsque vous écrivez un programme Java, il s'exécute sur toutes les plates - formes qui ont une JVM écrite pour elles-Windows, Linux, macOS, etc.
Si vous écrivez un programme C++, vous devrez compiler spécifiquement pour chaque plate-forme.
Maintenant, on dit que la devise de Java "écrire une fois, courir partout" est un mythe. Ce n'est pas tout à fait vrai pour les applications de bureau, qui nécessitent une interaction avec de nombreuses ressources natives, mais chaque application JavaEE peut être exécutée sur n'importe quelle plate-forme. Actuellement je travaille sur windows, et d'autres collègues travaillent sur Linux sans aucun problème.
(Une autre chose liée à la portabilité est JavaEE (enterprise edition). On dit que les applications écrites avec les technologies JavaEE s'exécutent dans n'importe quel serveur d'applications certifié JavaEE. Ceci, cependant, n'est pas vrai au moins jusqu'à JavaEE6. (voir ici))
La portabilité est une mesure de la quantité d'effort pour faire fonctionner un programme sur un autre environnement que celui d'où il est originaire.
Maintenant, vous pouvez débattre si une JVM sous Linux est un environnement différent de celui sous Windows (je dirais oui), mais le fait demeure que dans de nombreux cas, il n'y a aucun effort impliqué si vous prenez soin d'éviter quelques erreurs.
Le CVM dont vous parlez est en grande partie ce que les bibliothèques POSIX et les bibliothèques d'exécution essaient de fournir, mais il y a de gros les différences de mise en œuvre qui rendent les obstacles élevés à franchir. Certes, dans le cas de Microsoft et Apple, ils le sont probablement intentionnellement afin d'empêcher les développeurs de sortir des produits sur des plates-formes concurrentes.
Sur le front.net, si vous pouvez vous en tenir à ce que mono fournit, une implémentation. Net open source, vous profiterez à peu près du même type de portabilité que Java, mais comme mono est nettement en retard sur les versions Windows, ce n'est pas un choix populaire. Je l'ignore à quel point c'est populaire pour le développement basé sur serveur où je peux imaginer que c'est moins un problème.
Java est portable du point de vue du développeur: le code écrit en Java peut être exécuté dans n'importe quel environnement sans avoir besoin de recompiler. C est pas portable, car non seulement est-il lié à un système d'exploitation spécifique dans de nombreux cas, il est toujours lié à une architecture matérielle une fois qu'il a été compilé. La même chose est vraie pour C++. . Net est plus portable que C / C++, car il s'appuie également sur une machine virtuelle et n'est donc pas lié à une architecture matérielle spécifique au moment de la compilation, mais il est limité aux machines Windows (officiellement).
Vous avez raison, la JVM est spécifique à la plate-forme (elle doit l'être!), mais quand vous dites que Java est portable, vous en parlez du point de vue des développeurs et que les développeurs Java standard n'écrivent pas la JVM, ils l'utilisent :-).
Modifiez @ Raze2Dust Pour répondre à votre question. Oui, vous le pouvez. En fait, vous pouvez rendre Java spécifique à la plate-forme en écrivant un compilateur qui générerait du code machine plutôt que du bytecode. Mais comme certains parmi les autres commentaires suggèrent, pourquoi feriez-vous cela? Vous devez créer un interpréteur qui mappe le code compilé aux opérations de la même manière que la JVM fonctionne. Donc, le long et le court est, absolument, vous pourriez certainement, mais pourquoi le feriez-vous?
Vous demandez si on pourrait écrire une "C VM". Pas exactement. "Java" est un grand terme utilisé par Sun pour signifier beaucoup de choses, y compris à la fois le langage de programmation et la machine virtuelle. "C" n'est qu'un langage de programmation: c'est au compilateur, au système d'exploitation et au PROCESSEUR de décider du format du binaire résultant.
On dit parfois queC est portable car il ne spécifie pas le runtime. Les personnes qui ont écrit votre compilateur ont pu choisir des choses qui ont du sens pour cela plate. L'inconvénient est que C est assez bas niveau, et les plates-formes sont suffisamment différentes, qu'il est courant que les programmes C fonctionnent correctement sur un système et pas du tout sur un autre.
Si vous combinez le langage C avec un ABI spécifique, vous pouvez définir une machine virtuelle pour celui-ci, analogue à la JVM. Il y a déjà quelques choses comme ça, par exemple:
- La "Spécification de compatibilité binaire Intel" est un exemple d'un tel ABI (que presque personne n'utilise aujourd'hui)
- "Microsoft Windows " pourrait également être un tel ABI (bien qu'énorme et sous-spécifié), pour lequel Wine est une machine virtuelle qui exécute des programmes écrits pour elle
- "MS-DOS", pour lequel dosemu est une machine virtuelle
- ,"Linux", est l'un des plus populaires aujourd'hui, dont les programmes peuvent être exécutés par Linux lui-même, NetBSD, ou FreeBSD Il s'agit d'une machine virtuelle de type JIT (JIT-like VM), pour laquelle le Dynamo de HP était un ]}
Toutes ces machines virtuelles C sont en fait une vraie machine nobody personne, AFAIK, n'a jamais fait un C VM qui était purement virtuel. Ce n'est pas surprenant, car C a été conçu pour fonctionner efficacement sur le matériel, donc vous pourriez aussi bien le faire fonctionner normalement sur un seul système. Comme HP l'a montré, vous pouvez toujours faire un JIT pour exécuter le code plus efficacement, même sur la même plate-forme.
Java fournit trois types distincts de portabilité:
Portabilité du code source: Un programme Java donné doit produire des résultats identiques quel que soit le processeur sous-jacent, le système d'exploitation ou le compilateur Java.
Portabilité de l'architecture CPU: les compilateurs Java actuels produisent du code objet (appelé byte-code) pour un CPU qui n'existe pas encore. Pour chaque CPU réel sur lequel les programmes Java sont destinés à s'exécuter, un interpréteur Java, ou virtuel machine, "exécute" le J-code. Ce CPU inexistant permet au même code objet de s'exécuter sur n'importe quel CPU pour lequel un interpréteur Java existe.
Portabilité OS / GUI: Java résout ce problème en fournissant un ensemble de fonctions de bibliothèque (contenues dans les bibliothèques fournies par Java telles que awt, util et lang) qui parlent à un OS imaginaire et à une interface GRAPHIQUE imaginaire. Tout comme la JVM présente un processeur virtuel, les bibliothèques Java présentent un système d'exploitation/interface graphique virtuel. Chaque implémentation Java fournit des bibliothèques implémentation de ce système d'exploitation virtuel/GUI. Les programmes Java qui utilisent ces bibliothèques pour fournir le port de fonctionnalité OS et GUI nécessaire assez facilement.
Voir ce lien
Vous avez besoin de la JVM pour différentes architectures, mais bien sûr vos programmes Java s'exécutent sur cette JVM. Donc, une fois que vous avez une JVM pour une architecture, vos programmes Java sont disponibles pour l'architecture.
Je peux donc écrire un programme Java, le compiler en bytecode Java (qui est indépendant de l'architecture), et cela signifie que je peux l'exécuter sur n'importe quelle JVM sur n'importe quelle architecture. La JVM abstrait l'architecture sous-jacente et mon programme s'exécute sur une machine virtuelle.
L'idée est que le langage Java est portable (ou plus précisément, le code octet compilé est portable). Vous avez raison de dire que chaque machine virtuelle nécessite une implémentation spécifique pour un profil matériel donné. Cependant, une fois cet effort effectué, tout le bytecode java s'exécutera sur cette plate-forme. Vous écrivez le java / bytecode une fois, et il s'exécute sur n'importe quelle JVM.
. NET est assez similaire, mais avec un accent beaucoup plus faible sur le principe. Le CLR est analogue à la JVM et il a son propre bytecode. Mono existe sur *nix, mais vous avez raison de dire que ce n'est pas "officiel".
Portabilité ou comme écrit dans Wikipédia, Logiciel Portabilité est la possibilité de réutiliser le même logiciel (code) dans plusieurs environnements (Systèmes d'exploitation). La JVM java est une JVM qui peut être exécutée sur tous les systèmes d'exploitation pour lesquels elle a été conçue: Windows, Linux, Mac OS, etc.
Sur.NET, il est possible de porter votre logiciel sur différentes plates-formes. À Partir De Wikipedia:
La conception du framework. NET lui permet d'être théoriquement plate-forme agnostique, et ainsi, la croix-plate-forme compatible. Qui est un programme écrit pour utiliser le cadre doit s'exécuter sans changement sur tout type de système pour lequel le cadre est mettre.
Et parce que Microsoft n'a jamais implémenté le.NET framework en dehors de Windows et que. NET est indépendant de la plate-forme, Mono a permis d'exécuter des applications. NET et de compiler du code pour fonctionner sous Linux.
Pour des langages tels que C++, Pascal, etc. vous devrez aller à chaque système d'exploitation et de construire sur cette plate-forme afin de l'exécuter sur la plate-forme. Le fichier EXE dans Windows n'est pas le même que le .so dans linux (le code machine) car les deux utilisent des bibliothèques différentes pour parler au noyau et chaque système d'exploitation a son propre noyau.
WORE-Écrire Une fois Courir partout
En réalité, cela est limité aux plates-formes qui ont une JVM, mais cela couvre la majorité des plates-formes sur lesquelles vous souhaitez déployer. C'est presque à mi-chemin entre un langage interprété, et un langage compilé, gagne les avantages des deux.