Il y a un certain nombre de choses que Dalvik ne traitera pas ou pas tout à fait de la même manière que le bytecode Java standard, bien que la plupart d'entre elles soient assez avancées.
El L'exemple le plus grave est la génération de bytecode au moment de l'exécution. et le chargement de classes personnalisées. Imaginons que vous souhaitiez créer un bytecode et utiliser ensuite le classloader pour le charger à votre place. Si cette astuce fonctionne sur votre machine normale, il est garanti qu'elle ne fonctionnera pas sur Dalvik, à moins que vous ne changiez votre génération de bytecode.
Cela vous empêche d'utiliser certains cadres d'injection de dépendances, l'exemple le plus connu étant Google Guice (bien que je sois sûr que certaines personnes y travaillent). D'un autre côté, AspectJ devrait fonctionner car il utilise l'instrumentation du bytecode comme étape de compilation (mais je ne sais pas si quelqu'un a essayé).
Quant aux autres langages jvm, tout ce qui se compile en bytecode standard et n'utilise pas d'instrumentation de bytecode à l'exécution peut être converti en Dalvik et devrait fonctionner. Je sais que des personnes ont fait tourner Jython sur Android et que cela a bien fonctionné.
Une autre chose à savoir est qu'il y a pas de compilation juste à temps . Ce n'est pas strictement le problème de Dalvik (vous pouvez toujours compiler n'importe quel bytecode à la volée si vous le souhaitez) mais le fait qu'Android ne le supporte pas et qu'il est peu probable qu'il le fasse. En effet, alors que le microbenchmarking pour Java standard était inutile - les composants avaient des caractéristiques d'exécution différentes dans les tests et en tant que parties de systèmes plus grands - les microbenchmarks pour les téléphones Android ont totalement un sens.
