Pourquoi avons-nous besoin d'autres langues JVM?

https://stackoverflow.com/questions/85058

01-07-2019
|

Question

Je vois ici qu'il existe une multitude de langues en dehors de Java qui s'exécutent sur la machine virtuelle Java. Je suis un peu perplexe à propos du concept des autres langues en cours d'exécution dans la JVM. Donc:

Quel est l’avantage d’avoir d’autres langues pour la machine virtuelle Java?

Que faut-il (en termes de haut niveau) pour écrire un langage / compilateur pour la JVM?

Comment écrivez-vous / compilez-vous du code dans un langage (autre que Java) de la machine virtuelle?

MODIFIER: Trois questions de suivi (à l'origine des commentaires) ont été répondues dans la réponse acceptée. Ils sont reproduits ici pour plus de lisibilité:

Comment une application écrite, par exemple, JPython, pourrait-elle interagir avec une application Java?

De plus, cette application JPython peut-elle utiliser n’importe lequel des fonctions / objets JDK?

Et s’il s’agissait d’un code Jaskell, le fait qu’il s’agisse d’un langage fonctionnel ne le rendrait-il pas incompatible avec le JDK?

La solution

Pour répondre à vos trois questions séparément:

Quel est l’avantage d’avoir d’autres langues pour la machine virtuelle Java?

Il y a deux facteurs ici. (1) Pourquoi avoir un langage autre que Java pour la machine virtuelle Java et (2) pourquoi avoir un autre langage exécuté sur la machine virtuelle Java, au lieu d'un autre runtime?

D'autres langues peuvent satisfaire d'autres besoins. Par exemple, Java ne prend pas en charge les fermetures , une fonctionnalité souvent utilisée très utile.
Une langue qui s'exécute sur la machine virtuelle Java est compatible avec tout autre langage s'exécutant sur la machine virtuelle. En d'autres termes, le code écrit dans une langue peut interagir avec une bibliothèque écrite dans une autre langue.

Qu'est-ce qui est nécessaire (en termes généraux) pour écrire un langage / compilateur pour la machine virtuelle?

La machine virtuelle Java lit les fichiers de type bytecode (.class) pour obtenir les instructions nécessaires. Par conséquent, toute langue devant être exécutée sur la machine virtuelle Java doit être compilée en un bytecode conforme au Spécification Sun . Ce processus est similaire à la compilation en code natif, excepté qu'au lieu de compiler des instructions comprises par le CPU, le code est compilé en instructions interprétées par la machine virtuelle.

Comment écrivez-vous / compilez-vous du code dans un langage (autre que Java) de la machine virtuelle?

De la même manière que vous écrivez / compilez / exécutez du code en Java. Pour bien vous familiariser avec la situation, je vous conseillerais de regarder Scala , qui fonctionne parfaitement sur la JVM.

Répondre à vos questions suivantes:

Comment une application écrite en JPython, par exemple, interagirait-elle avec une application Java?

Cela dépend du choix de l'implémentation de combler le fossé linguistique. Dans votre exemple, le projet Jython dispose d'un moyen simple de le faire ( voir ici ):

from java.net import URL
u = URL('http://jython.org')

De plus, cette application JPython peut-elle utiliser l’un des objets / fonctions JDK?

Oui, voir ci-dessus.

Et s’il s’agissait d’un code Jaskell, le fait qu’il s’agisse d’un langage fonctionnel ne le rendrait-il pas incompatible avec le JDK?

Non. Scala (lien ci-dessus), par exemple, implémente des fonctionnalités fonctionnelles tout en maintenant la compatibilité avec Java. Par exemple:

object Timer {
  def oncePerSecond(callback: () => unit) {
    while (true) { callback(); Thread sleep 1000 }
  }
  def timeFlies() {
    println("time flies like an arrow...")
  }
  def main(args: Array[String]) {
    oncePerSecond(timeFlies)
  }
}

Autres conseils

Vous avez besoin d'autres langages sur la machine virtuelle Java pour la même raison que plusieurs langages de programmation en général: Différents langages permettent mieux de résoudre différents problèmes ... typage statique vs typage dynamique, strict vs fainéant ... Déclaratif, Impératif , Orienté objet ... etc.

En général, écrire un "compilateur" Pour qu’un autre langage puisse s’exécuter sur la machine virtuelle (ou sur le .Net CLR), il s’agit essentiellement de compiler ce langage en bytecode java (ou, dans le cas de .Net, IL) au lieu du langage assembleur / machine.

Cela dit, de nombreux langages supplémentaires écrits pour JVM ne sont pas compilés, mais plutôt interprétés par des langages de script ...

En revenant sur ce point, envisagez de créer un nouveau langage et de l’exécuter dans un environnement d’exécution géré avec un JIT et un GC. Ensuite, considérez que vous pourriez:

(a) écrivez votre propre runtime (VM) et résolvez toutes sortes de problèmes techniquement difficiles qui entraîneront sans doute de nombreux bugs, de mauvaises performances, des threads incorrects et de nombreux efforts de portabilité

(b) compilez votre langage en un bytecode pouvant s'exécuter sur la machine virtuelle Java déjà bien mature, rapide et prise en charge sur plusieurs plates-formes (parfois avec plusieurs choix d'implémentation fournisseur).

Etant donné que le bytecode JavaVM n'est pas trop lié au langage Java au point de restreindre indûment le type de langage que vous pouvez implémenter, il s'agit d'un environnement cible populaire pour les langages souhaitant s'exécuter sur une machine virtuelle.

Java est un langage de programmation assez prolixe qui devient rapidement obsolète avec tous les nouveaux langages / frameworks fantaisistes apparus au cours des 5 dernières années. Pour prendre en charge toute la syntaxe sophistiquée souhaitée par les utilisateurs d'une langue ET préserver la compatibilité ascendante, il est plus logique d'ajouter davantage de langues à l'exécution.

Un autre avantage est qu’il vous permet d’exécuter des frameworks Web écrits en Ruby ala JRuby (alias Rails), ou Grails (Groovy sur Railys essentiellement), etc. sur une plate-forme d’hébergement éprouvée qui est probablement déjà en production dans de nombreuses entreprises. d’avoir à utiliser des environnements d’hébergement Ruby qui n’ont pas été aussi éprouvés.

Pour compiler les autres langages que vous convertissez en code octet Java.

Je répondrais, & # 8220; car Java est nul & # 8221; mais encore une fois, c'est peut-être trop évident & # 8230; & nbsp ;; -)

L’avantage d’avoir d’autres langues pour la machine virtuelle Java est assez semblable à celui d’avoir d’autres langues d’ordinateur en général: alors que toutes les langues complètes peuvent effectuer techniquement les mêmes tâches, certaines langues rendent certaines tâches plus faciles que d’autres, tandis que d'autres langues facilitent d'autres tâches. Étant donné que la machine virtuelle Java est quelque chose que nous avons déjà la capacité de faire fonctionner sur tous les ordinateurs (et presque tous), et beaucoup d’ordinateurs, en fait, nous pouvons déjà obtenir le code "écrire une fois, exécuter n'importe où". avantage, mais sans exiger que l’on utilise Java.

L’écriture d’un langage / compilateur pour la machine virtuelle Java n’est pas très différente de l’écriture pour une machine réelle. La vraie différence réside dans le fait que vous devez compiler le bytecode de la JVM au lieu du code exécutable de la machine, mais il s’agit là d’une différence mineure dans le grand schéma.

L'écriture de code pour un langage autre que Java dans la machine virtuelle Java n'est pas vraiment différente de l'écriture en Java, sauf bien sûr que vous utiliserez un langage différent. Vous compilerez en utilisant le compilateur écrit par quelqu'un (encore une fois, pas très différent d'un compilateur C, fondamentalement et pratiquement pas du tout d'un compilateur Java), et vous finirez par pouvoir l'exécuter simplement. comme vous le feriez pour le code Java compilé, car une fois en bytecode, la machine virtuelle Java ne peut pas dire de quelle langue elle provient.

Différentes langues sont adaptées à différentes tâches. Bien que certains domaines problématiques s’adaptent parfaitement au langage Java, d’autres sont beaucoup plus faciles à exprimer dans d’autres langages. De plus, pour un utilisateur habitué à Ruby, Python, etc., la possibilité de générer du bytecode Java et de tirer parti des classes JDK et le compilateur JIT présente des avantages évidents.

Répondez simplement à votre deuxième question:

La machine virtuelle Java n’est qu’une machine abstraite et un modèle d’exécution. Par conséquent, le cibler avec un compilateur est identique à tout autre modèle de machine et d'exécution qu'un compilateur pourrait cibler, qu'il soit implémenté dans du matériel (x86, CELL, etc.) ou dans un logiciel (parrot, .NET). La JVM est assez simple, ce qui en fait une cible assez facile pour les compilateurs. De plus, les implémentations ont tendance à avoir de très bons compilateurs JIT (pour traiter le code moche produit par javac), vous pouvez donc obtenir de bonnes performances sans vous soucier de nombreuses optimisations.

Quelques mises en garde s’appliquent. Premièrement, la machine virtuelle Java incorpore directement le module et le système d'héritage de Java. Il est donc probable qu'essayer de faire autre chose (héritage multiple, envoi multiple) sera délicat et nécessitera du code compliqué. Deuxièmement, les machines virtuelles sont optimisées pour traiter le type de bytecode produit par javac. Produire du bytecode qui est très différent de celui-ci va probablement entrer dans des recoins étranges du compilateur JIT / JVM qui seront probablement au mieux inefficaces (au pire, ils peuvent planter la JVM ou au moins donner des exceptions parasites VirtualMachineError).

Ce que la machine virtuelle Java peut faire est défini par le bytecode (ce que vous trouvez dans les fichiers .class) plutôt que par la langue source. Donc, changer le langage de code source de haut niveau n'aura pas d'impact significatif sur les fonctionnalités disponibles.

Pour ce qui est nécessaire pour écrire un compilateur pour la machine virtuelle Java, tout ce que vous avez à faire est de générer des fichiers corrects en bytecode / .class. La manière dont vous écrivez / compilez le code avec une autre sorte de compilateur dépend du compilateur en question, mais une fois que le compilateur génère les fichiers .class, leur exécution ne diffère pas de celle des fichiers .class générés par javac.

L'avantage de ces autres langues est qu'elles ont un accès relativement facile à de nombreuses bibliothèques java.

L’avantage pour les utilisateurs de Java varie en fonction de la langue: chacun a une histoire qui raconte aux codeurs Java ce qu’ils font de mieux. Certains insisteront sur la manière dont ils peuvent être utilisés pour ajouter des scripts dynamiques aux applications basées sur JVM, d'autres se contenteront de dire que leur langage est plus facile à utiliser, a une meilleure syntaxe, etc.,

Ce qui est requis, c’est la même chose pour écrire un compilateur dans un autre langage: analyser en AST, puis le transformer en instructions pour l’architecture cible (code octet) et le stocker au bon format (fichiers .class).

Du point de vue des utilisateurs, il vous suffit d'écrire du code et d'exécuter les fichiers binaires du compilateur. Il en résulte des fichiers .class que vous pouvez mélanger avec ceux que votre compilateur Java produit.

Les langages .NET sont plus utiles à l’affichage qu’à l’utilité réelle. Chaque langue a été tellement dépeinte qu’elles sont toutes en C # avec un nouveau visage.

Il existe diverses raisons de fournir des langages alternatifs pour la machine virtuelle Java:

La machine virtuelle Java est multiplateforme. Toute langue portée sur la machine virtuelle Java bénéficie de ce bonus gratuit.
Il existe pas mal de code hérité. Les moteurs obsolètes tels que ColdFusion offrent de meilleures performances tout en offrant aux clients la possibilité de passer progressivement de la solution héritée à la solution moderne.
Certaines formes de script conviennent mieux à un développement rapide. JavaFX, par exemple, est conçu pour un développement graphique rapide. De cette façon, il entre en concurrence avec des moteurs tels que DarkBasic. (Le traitement est un autre joueur dans cet espace.)
Les environnements de script peuvent offrir un contrôle. Par exemple, une application peut souhaiter exposer un environnement de type VBA à l'utilisateur sans exposer les API Java sous-jacentes. L'utilisation d'un moteur tel que Rhino peut fournir un environnement prenant en charge le codage rapide et sale dans un bac à sable soigneusement contrôlé.
Les scripts interprétés signifient qu'il n'est pas nécessaire de recompiler quoi que ce soit. Pas besoin de recompiler se traduit par un environnement plus dynamique. par exemple. En dépit de l'utilisation de Java en tant que "langage de script" par OpenOffice, Java convient à cet usage. L’utilisateur doit passer par toutes sortes de girations de recompilation / rechargement non nécessaires dans un environnement de script dynamique tel que Javascript.
Ce qui m'amène à un autre point. Les moteurs de script peuvent être plus facilement arrêtés et rechargés sans arrêter et recharger la totalité de la machine virtuelle Java. Cela augmente l'utilité du langage de script car l'environnement peut être réinitialisé à tout moment.

Il est beaucoup plus facile pour un rédacteur de compilateur de générer des codes d'octet JVM ou CLR. Ils sont beaucoup plus propres et ont un niveau d'abstraction supérieur à celui de tout langage machine. Pour cette raison, il est beaucoup plus faisable de créer de nouveaux langages que jamais auparavant, car il vous suffit de cibler l'une de ces architectures de VM et vous aurez un ensemble d'outils et de bibliothèques déjà disponibles pour votre langage. Ils permettent aux concepteurs de langues de se concentrer davantage sur le langage que sur l’ensemble des infrastructures de support nécessaires.

Parce que le processus JSR rend Java de plus en plus mort: http: / /www.infoq.com/news/2009/01/java7-updated

Il est dommage que même des ajouts essentiels et connus depuis longtemps, tels que Closures, ne soient pas ajoutés simplement parce que les membres ne peuvent pas se mettre d'accord sur une implémentation.

Java a accumulé une base d'utilisateurs massive sur sept versions majeures (de 1.0 à 1.6). Sa capacité à évoluer est limitée par la nécessité de préserver la compatibilité ascendante pour les innombrables millions de lignes de code Java exécutées en production.

Ceci pose un problème car Java doit évoluer vers:

faites concurrence aux nouveaux langages de programmation tirés des succès et des échecs de Java.
incorporez de nouvelles avancées dans la conception de langage de programmation.
permettre aux utilisateurs de tirer pleinement parti des avancées matérielles - par exemple. processeurs multicœurs.
corrigez des idées pointues introduisant des problèmes inattendus (exceptions vérifiées, génériques, etc.).

L'exigence de compatibilité ascendante est un obstacle à la compétitivité.

Si vous comparez Java à C #, Java présente un avantage en termes de bibliothèques et de frameworks prêts à la production, ainsi qu’un inconvénient en termes de fonctionnalités de langage et de taux de croissance de la part de marché. C’est ce à quoi on pourrait s’attendre en comparant deux langues réussies et séparées d’une génération à l’autre.

Tout nouveau langage présente les mêmes avantages et inconvénients que C # a comparé à Java à un degré extrême. Un moyen de maximiser l’avantage en termes de fonctionnalités de langage et de minimiser l’inconvénient en termes de bibliothèques et de frameworks matures consiste à créer le langage d’une machine virtuelle existante et à le rendre interopérable avec le code écrit pour cette machine virtuelle. C'est la raison du succès modeste de Groovy et Clojure; et l'excitation autour de Scala. Sans la machine virtuelle Java, ces langues n'auraient jamais occupé qu'une petite niche dans un segment de marché très spécialisé, alors qu'avec la machine virtuelle Java, elles occupent une place importante dans le marché principal.

Ils le font pour suivre. Net. .Net permet C #, VB, J # (anciennement), F #, Python, Ruby (à venir) et c ++. Je manque probablement certains. Le plus important ici est probablement Python, pour les scripteurs.

Dans une certaine mesure, il s’agit probablement d’une "course aux armements" contre le .NET CLR.

Mais je pense qu'il existe également de véritables raisons d'introduire de nouveaux langages dans la machine virtuelle, en particulier lorsqu'ils seront exécutés "en parallèle": vous pouvez utiliser le bon langage pour le bon travail. Un langage de script comme Groovy peut être exactement ce que vous voulez. vous avez besoin pour la présentation de votre page, alors que l'ancienne version de Java est préférable pour votre logique métier.

Je vais laisser quelqu'un de plus qualifié pour parler de ce qui est nécessaire pour écrire un nouveau langage / compilateur.

En ce qui concerne la rédaction de code, vous le faites dans le bloc-notes / vi comme d’habitude! (ou utilisez un outil de développement qui prend en charge le langage si vous voulez le faire facilement.) La compilation nécessitera un compilateur spécial pour le langage qui l'interprétera et le compilera en bytecode.

Etant donné que Java produit également du code octet sur le plan technique, vous n'avez rien de spécial à faire pour l'exécuter.

La raison en est que la plate-forme JVM offre de nombreux avantages.

Nombre géant de bibliothèques
Plus large degré de plate-forme implémentations
cadres matures
Code hérité qui est fait déjà partie de votre infrastructure

Les langages que Sun essaie de prendre en charge avec ses spécifications de script (par exemple, Python, Ruby) sont en hausse et viennent en grande partie à cause de leurs améliorations de productivité perçues. Exécuter Jython vous permet théoriquement d’être plus productif et d’exploiter les capacités de Python pour résoudre un problème mieux adapté à Python, tout en étant capable d’intégrer, au niveau de l’exécution, avec code base. Les implémentations classiques de Python et Ruby confèrent la même capacité aux bibliothèques C .

De plus, il est souvent plus facile d'exprimer certaines choses dans un langage dynamique qu'en Java. Si tel est le cas, vous pouvez aller dans l'autre sens. utiliser les bibliothèques Python / Ruby de Java .

Les performances ont baissé, mais beaucoup acceptent de l'accepter en échange d'une base de code moins explicite et plus claire.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow