Qu'est-ce qui diffère entre «écrire un JRE spécifique pour chaque plate-forme» pour les développeurs Java et «écrire un compilateur C ++ pour chaque plate-forme» pour les développeurs C ++?
Qu'est-ce qui diffère entre «écrire un JRE spécifique pour chaque plate-forme» pour les développeurs Java et «écrire un compilateur C ++ pour chaque plate-forme» pour les développeurs C ++?
Réponses:
Java est compilé une fois exécuté n'importe où. C ++ est écrit une fois compilé n'importe où.
«écrire un JRE spécifique pour chaque plate-forme» n'est pas quelque chose que vous faites à chaque fois. Le portage du JRE sur une nouvelle plateforme est quelque chose que vous devez faire une seule fois. Cette tâche est généralement effectuée par le principal mainteneur / développeurs du programme et / ou de la plate-forme. De nombreux facteurs peuvent entrer en jeu pour décider qui et comment le JRE sera porté. Entre autres choses, cela dépend de la licence sous laquelle il est publié (j'entends que Java est Open Source, donc je suppose que n'importe qui pourrait le faire). Anecdote drôle, Steve Jobs a fait une grosse affaire de ne pas vouloir s'occuper du portage de Java sur Mac , il y a environ un an.
Il ne s'agit pas de savoir comment ou qui portera le JRE, mais le fait qu'une fois qu'il est porté, chaque application Java devrait désormais théoriquement s'exécuter facilement sur la nouvelle machine. En ce sens, le JRE forme une couche d'abstraction, cachant complètement la machine, permettant un portage facile.
Cependant, la réalité n'est pas toujours aussi jolie. Je n'irai pas jusqu'à qualifier la portabilité de "mythe", mais c'est vrai que ce n'est pas si parfait. Par exemple, Java a un package appelé JNIqui permet d'envoyer des appels natifs, en contournant le JRE, empêchant ainsi la portabilité parfaite parfaite, ce que les fans de Java aiment appeler "Écrire une fois exécuté partout".
Comme mentionné dans les commentaires, l'approche de C ++ en matière de portabilité est différente. D'une part, c'est un langage compilé, et ces binaires sont presque toujours spécifiques à la plate-forme. Ainsi, les exécutables c ++ ne seront jamais portables (contrairement à Java). En revanche, le portage du compilateur peut parfois suffire. La communauté a découvert qu'en portant le compilateur ainsi que certaines bibliothèques de base du langage, les codes source (et non les binaires) pouvaient être portables.
Cependant, le C ++ est largement utilisé dans les systèmes critiques comme les compilateurs, les noyaux, les systèmes en temps réel, les systèmes embarqués, ... Il y a un aspect "bas niveau" du C ++ qui ne peut pas être négligé, quand on parle de portabilité.
Ce n'est pas seulement la langue - ce sont les bibliothèques.
Java et C ++ fournissent des bibliothèques multiplateformes. Java fournit un ensemble plus riche.
La différence est que Java fonctionnera sur n'importe quelle plate-forme sans recompilation. Avoir un compilateur C ++ pour chaque plate-forme n'est pas du tout le même.
Toutes les réponses commençant par "La différence est ...", ou quelque chose de très similaire, sont fondamentalement erronées (désolé, mais telle est la vie). Il y a vraiment deux différences distinctes entre les deux.
L'une (qui a été souvent mentionnée) est qu'un programme Java compilé peut (ou du moins devrait) s'exécuter sur n'importe quelle implémentation conforme de Java, donc même après avoir été compilé, vous pouvez toujours déplacer un programme Java d'une plate-forme à une autre sans recompiler . C ++ (au moins normalement) nécessite une recompilation pour chaque plate-forme cible.
L'autre est que Java (au moins tente de) s'assurer que tout Java correctement écrit sera portable. Au moins en théorie, vous ne devriez pas pouvoir écrire de code qui n'est pas portable.
C ++ vous permet de faire pas mal de choses qui ne sont pas portables. La norme C ++ contient des "avertissements" sur beaucoup de choses qui ne sont pas portables (par exemple, vous dire que vous obtiendrez un comportement défini par l'implémentation ou un comportement non défini), mais il n'essaie pas nécessairement de vous empêcher de les faire du tout . Par exemple, si vous souhaitez écrire un système d'exploitation pour du matériel utilisant un bus PCI, vous devrez probablement lire / écrire la mémoire de configuration PCI. Cela ne sera évidemment pas portable sur les systèmes sans bus PCI, mais si vous écrivez un système d'exploitation pour le matériel avec un bus PCI, c'est à peu près nécessaire. C ++ le permet même s'il n'est évidemment pas portable.
Vous avez mal compris les lieux. Les programmes Java sont très portables, car la JVM fournit un comportement standard garanti identique. Les programmes C ++ ont un environnement moins standardisé plus proche du matériel réel, donc le programme doit être capable de gérer les différents détails spécifiques à la plate-forme - comme la taille d'un int, l'alignement des mots, etc., etc.
La JVM elle-même n'est pas très portable. C'est une tâche herculéenne de porter une JVM hautement performante sur une autre plate-forme ou architecture de CPU.
La différence est que les programmes Java (ce n'est pas un acronyme) peuvent être distribués sous une forme qui peut être exécutée sur n'importe quel ordinateur sur lequel une machine virtuelle Java est installée, mais C ++ est normalement distribué en tant que code source, qui est très peu convivial pour l'utilisateur, ou en tant que groupe de différents binaires pour différentes plates-formes.
L'une des raisons pour lesquelles Java est considéré comme portable est qu'il a des règles spécifiques sur la façon dont les expressions arithmétiques doivent être évaluées et interdit les implémentations de les évaluer de toute autre manière, même lorsque les évaluer de la manière prescrite nécessiterait un code plus lent que de les évaluer de manière plus précise. mode.
Par exemple, étant donné
long thing1(int x) {
return (x+1)-1L;
}
double thing2(int x, float y) {
return x/y;
}Les valeurs de thing1(2147483647)et thing2(1123456700,11234567.0f)doivent être respectivement -2147483649L et 99,9999923706054688, même si les valeurs arithmétiquement correctes seraient 2147483647L et 100,0, et même si sur certaines plates-formes, le code pour générer des résultats numériquement incorrects serait plus lent que le code pour générer le code correct. résultats (sur certaines plates-formes 64 bits, forcer le comportement d'habillage après (x + 1) nécessiterait une instruction supplémentaire, et sur la plate-forme 8x87, forcer la valeur de 1123456700 à être arrondi à floatnécessiterait une instruction supplémentaire par rapport au simple chargement directement à un registre à précision étendue).
(int)pour la (x+1)sous - expression du premier exemple dans le premier exemple, au paramètre floatdu deuxième exemple x, mais évidemment je n'ai pas conçu le langage .
La quantité de travail pour les outils de support est en effet similaire, la différence est ailleurs. Une fois qu'un programme C ++ a été compilé pour une plate-forme, vous devez le recompiler si vous souhaitez l'utiliser sur une plate-forme différente. Cependant, lorsqu'un programme java a été compilé, vous pouvez le déplacer vers n'importe quelle autre plate-forme avec un environnement d'exécution sans avoir à le recompiler.
En répondant au titre "La portabilité est-elle un mythe?", Au lieu de "Qui est meilleur en portabilité, Java ou C ++", je dirai que la portabilité partielle est possible, mais la portabilité complète est un mythe.
Quelque chose que j'insiste à écrire, et cela s'applique à cette question, c'est que les développeurs ne travaillent plus uniquement avec des langages de programmation, mais avec des cadres de programmation complets.
Et ces cadres, incluent des bibliothèques, des bases de données, des interfaces graphiques.
Quel langage de programmation ou quel cadre de programmation est plus portable?
Eh bien, cela dépend de ce que votre application. essaie d'atteindre.
Le fait est que "vous" n'écrivez pas le JRE, vous écrivez le code Java qui s'exécute sur n'importe quel JRE. "Vous" écrivez le code C ++ qui peut nécessiter des modifications de votre part avant qu'il ne soit compilé sur une autre plate-forme.
Beaucoup de gens oublient ou ne prennent pas en compte la réalité de Java quand ils disent que "c'est 100% portable" ou des phrases comme ça.
Presque toutes les grandes sociétés / éditeurs de logiciels avaient au moins une implémentation maison de Java avec un JRE associé dans un passé récent et certains le maintiennent toujours, Microsoft, IBM et Apple, par exemple, avaient tous leur propre version de Java reflétant leur ses propres idées et réflexions sur l’orientation de l’industrie et de ce langage.
Comment est-ce pour "portable"? Un JRE partout où vous vous tournez.
Et cela sans tenir compte de ce que faisait Sun / Oracle.
Un exemple sur la raison pour laquelle le code Java n'est pas vraiment loin du C et C ++ en termes de portabilité sont les GUI et les serveurs graphiques, Apple avait une implémentation non standard du cadre GUI pour son propre JRE, en conséquence, il y avait beaucoup de des maux de tête et un double travail pour tous ceux qui voulaient créer / porter une interface graphique à l'aide de Java pour les machines Apple et ils ont été essentiellement obligés de gérer Quartz (comment est-ce en termes de "levier" et de langages de haut niveau?).
Parfois, même les mots les plus utilisés ne reflètent pas vraiment le sens que les gens leur donnent habituellement. Pour moi, le terme "portabilité" dans le monde Java ressemble plus à "perspectives" au sens commun; en termes commerciaux et financiers, il y a de meilleures perspectives pour vous si vous adoptez Java plutôt que d'autres langages (au moins au moment où Java est né) car vous avez déjà beaucoup de travail d'un côté (vous obtenez un JRE sur n'importe quoi qui peut être considéré comme un "ordinateur") et votre base de code est susceptible d'être portable telle quelle, vous avez besoin de moins de ressources pour porter votre programme, c'est tout, que cette ressource soit de l'argent, du temps ou de la main-d'œuvre n'a pas d'importance, c'est moins seuil par rapport à d'autres technologies et c'est à cela que sert Java, il abaisse ce seuil.
Bien sûr, cela est vrai si vous acceptez les prémisses de Java, ce qui signifie une machine virtuelle avec garbage collection, ce qui signifie qu'elle consomme plus de ressources par rapport aux langues natives, si vous voulez vraiment tirer le maximum de votre CPU ou batterie de serveurs I ne pensez pas que vous pouvez adopter Java à moins que vous soyez vraiment à court de ressources ou que votre entreprise soit vraiment petite.
Je dois encore trouver une seule application Java non triviale qui ne contient qu'une seule version pour chaque ligne de code ou fonctionnalité (c'est-à-dire sans aucun élément spécifique à la plate-forme) et elle est 100% portable parmi tous les principaux JRE.