Fonctionnalités Bytecode non disponibles dans le langage Java

Question

Y at-il actuellement (Java 6) des choses que vous pouvez faire en bytecode Java que vous ne pouvez pas faire depuis le langage Java?

Je sais que les deux sont Turing complet, donc lire "peut faire" car "peut faire beaucoup plus vite / mieux, ou simplement d'une manière différente".

Je pense à des bytecodes supplémentaires comme invokedynamic , qui ne peuvent pas être générés avec Java, sauf que celui-ci est destiné à une version future.

Answer 1

Autant que je sache, il n'y a pas de fonctionnalités majeures dans le bytecode pris en charge par la version 6 de Java qui ne sont pas également accessibles à partir du code source Java. La principale raison pour cela est de toute évidence que le bytecode Java a été conçu avec le langage Java à l'esprit.

Il y a certaines fonctionnalités qui ne sont pas produits par les compilateurs Java, cependant:

• L' ACC_SUPER drapeau:

  C'est un indicateur qui peut être définie sur une classe et précise la façon dont un cas de coin de l' invokespecial bytecode est manipulé pour cette classe. Il est défini par tous les compilateurs Java (où "moderne" est >= Java 1.1, si je me souviens bien) et seuls les anciens compilateurs Java produit des fichiers de classe où c'était de l'onu. Ce drapeau n'existe qu'en arrière pour des raisons de compatibilité.

• L' jsr/ret bytecode.

  Ces bytecode ont été utilisés pour mettre en œuvre des sous-routines (surtout pour la mise en œuvre de finally blocs). Ils sont plus produites depuis la version 6 de Java. La raison de leur abandon, c'est qu'ils compliquer statique de vérification beaucoup pour pas grand gain (c'est à dire un code qui utilise peut presque toujours être implémentés avec des sauts normaux avec très peu de frais généraux).

• Avoir deux méthodes dans une classe qui ne diffèrent que par le type de retour.

  Le langage Java spécification ne permet pas à deux méthodes dans la même classe quand ils diffèrent seulement dans leur type de retour (c'est à dire même nom, le même argument de la liste, ...). La spécification de la JVM n'a toutefois pas d'une telle restriction, de sorte qu'un fichier de classe peut contenir deux de ces méthodes, il n'y a tout simplement aucun moyen de produire un fichier de classe à l'aide de la normale compilateur Java. Il y a un bel exemple/explication de cette réponse.

Answer 2

Voici quelques caractéristiques qui peuvent être faites dans le bytecode Java, mais pas dans le code source de Java:

• Jetant un checked exception à partir d'une méthode sans avoir à déclarer que la méthode se jette sur elle. Le activée et désactivée exceptions sont une chose qui n'est vérifiée que par le compilateur de Java, pas de la JVM. En raison de cette par exemple Scala pouvez jeter checked exceptions de méthodes, sans le déclarer. Mais avec les generics de Java il y a une solution appelée sournois jeter.

• Avoir deux méthodes dans une classe qui ne diffèrent que par le type de retour, comme déjà mentionné dans de Joachim réponse: Le langage Java spécification ne permet pas à deux méthodes dans la même classe quand ils diffèrent seulement dans leur type de retour (c'est à dire même nom, le même argument de la liste, ...). La spécification de la JVM n'a toutefois pas d'une telle restriction, de sorte qu'un fichier de classe peut contenir deux de ces méthodes, il n'y a tout simplement aucun moyen de produire un fichier de classe à l'aide de la normale compilateur Java. Il y a un bel exemple/explication de cette réponse.

Answer 3

• GOTO peut être utilisé avec des étiquettes pour créer vos propres structures de contrôle (autres que for while etc)
• Vous pouvez remplacer l' this variable locale à l'intérieur d'une méthode
• En combinant les deux de ces, vous pouvez créer queue appel optimisé bytecode (je le fais dans JCompilo)

Comme un point connexe, vous pouvez obtenir de nom de paramètre pour les méthodes si compilé avec la fonction de débogage (Paranamer fait en lisant le pseudo-code

Answer 4

Peut-être que la section 7A de ce document est intéressante, même si elle concerne des pièges de bytecode plutôt que des caractéristiques de bytecode.