Quelles sont les constructions utiles (pour la performance ou autres) qui sont valides en bytecode, mais qui ne sont pas exprimables en Java?Quelles tâches de bas niveau peuvent être accomplies sur la JVM, mais pas exprimées en java?
Le bytecode JVM est un stack-oriented programming language, donc la plupart des instructions de gestion de pile n'ont pas de sens en Java, par ex. dup, swap, etc. Arbitraire goto, bien sûr, n'est pas non plus exprimable en Java. Quelque chose comme JSR 292 propose un support pour les langages typés dynamiquement, ce que je ne pense pas que Java envisage de devenir.
Je pense que quelque chose doit être abordé ici, cependant: votre question semble être motivée au moins en partie par la question de la performance. En pratique, les bytecodes sont compilés en JIT pour l'assemblage. Qu'il y ait ou non une instruction de super bytecode magique est vraiment très discutable.
J'ai lu que les signatures de méthode de bytecode prennent en charge l'envoi multiple sur types de retour, alors que Java ne permet que des méthodes du même nom sur types expédier des paramètres.
Par la même occasion, vous pouvez probablement récupérer des champs avec le même nom mais aussi des types différents. – polygenelubricants
L'inverse est également vrai parfois. Par exemple, la visibilité de Java des classes internes ne peut pas être représentée dans le bytecode. La JVM ne connaît que la visibilité protégée par un paquet, protégée, publique et privée. Le compilateur Java doit donc utiliser un hack: Il génère des méthodes wrapper synthétiques (qui sont visibles par le paquet) pour exposer les champs privés et les méthodes des classes internes à la classe externe.
La visibilité des classes internes est représentée dans le bytecode à l'aide des attributs INNERCLASS/OUTERCLASS. –
Tout peut-il raisonnablement être laissé au JIT? Peut-être quelque chose comme garantir l'allocation de la pile? –