Groovy, Scala et Java sous le capot

Question

J'ai utilisé Java pendant 6-7 ans, mais il y a quelques mois, j'ai découvert Groovy et j'ai commencé à économiser beaucoup de temps de frappe... Ensuite, je me suis demandé comment certaines choses fonctionnaient sous le capot (parce que les performances de groovy sont vraiment médiocres) et j'ai compris que pour vous donner dactylographie dynamique cada Groovy est un objet MetaClass qui gère toutes les choses que la JVM ne peut pas gérer elle-même. Bien sûr, cela introduit une couche intermédiaire entre ce que vous écrivez et ce que vous exécutez, ce qui ralentit tout.

Il y a quelques jours, j'ai commencé à recevoir des informations sur les sujets suivants Scala . Comment ces deux langues se comparent-elles dans leurs traductions du code d'octets ? Combien de choses ajoutent-ils à la structure normale que l'on obtiendrait par un code Java simple ?

Je veux dire.., Scala es statique typée , de sorte qu'une enveloppe de Java devraient être plus légères, puisque beaucoup de choses sont vérifiées au moment de la compilation, mais je ne suis pas sûr des différences réelles de ce qui se passe à l'intérieur. (Je ne parle pas de l'aspect fonctionnel des classes de Scala par rapport aux autres, c'est différent)

Quelqu'un peut-il m'éclairer ?

De Commentaires de SyntaxT3rr0r il semble que la seule façon d'obtenir moins de typage et la même performance soit d'écrire un traducteur intermédiaire qui traduise quelque chose en Java (en laissant javac le compiler) sans modifier la façon dont les choses sont exécutées, en ajoutant simplement du sucre syntaxique sans se soucier des autres retombées du langage lui-même.

Answer 1

Les autres réponses se concentrent sur les spécificités de Scala. J'aimerais ajouter quelques points pour le cas générique. Tout d'abord, il est tout à fait possible d'écrire un générateur de bytecode qui produit du javac -mais à partir d'un langage qui n'est pas Java. Cela devient plus difficile à mesure que la sémantique du langage diffère de celle de Java. Le typage explicite ne fait cependant pas partie de la sémantique, mais seulement de la syntaxe (et il a des propriétés de détection d'erreurs).

Les performances diminuent lorsque les types ne peuvent pas être déterminés de manière statique (au moment de la compilation) ou si le langage est dynamique par nature (le typage est dynamique comme dans de nombreux langages de script tels que le JavaScript , Jython , JRuby etc.) Dans ces cas, avec le JDK 1.6, vous devez effectuer un dispatching basé sur la réflexion. Cela est évidemment plus lent et ne peut pas être facilement optimisé par hotspot / la machine virtuelle. Le JDK 1.7 étend invokedynamic, de sorte qu'il peut être utilisé pour appeler une fonction de manière dynamique, comme le font les langages de script.

Les javac n'effectue pas beaucoup d'optimisations (le compilateur JVM les fait au moment de l'exécution), de sorte que le langage Java se traduit assez directement par le bytecode Java. Cela signifie que les langages ayant la même sémantique ont un avantage par rapport aux langages ayant une sémantique différente. Il s'agit d'un inconvénient de la JVM et d'un endroit où le CLR ( .NET ) et LLVM présentent des avantages évidents.