Les méthodes par défaut nécessitent de telles modifications du bytecode et de la JVM qu'elles auraient été impossibles à faire sur Java 7. Le vérificateur de bytecode de Java 7 et inférieur rejettera les interfaces avec les corps de méthode (à l'exception de la méthode d'initialisation statique). Essayer d'émuler les méthodes par défaut avec des méthodes statiques du côté appelant ne produirait pas les mêmes résultats, car les méthodes par défaut peuvent être remplacées dans les sous-classes. Retrolambda a une prise en charge limitée des méthodes de rétroportage par défaut, mais il ne peut jamais être complètement rétroporté car il nécessite vraiment de nouvelles fonctionnalités JVM.
Lambdas pourrait s'exécuter sur Java 7 tel quel, si les classes d'API nécessaires y existaient. L'instruction invokedynamic existe sur Java 7, mais il aurait été possible d'implémenter des lambdas pour qu'elle génère les classes lambda au moment de la compilation (les premières versions de JDK 8 l'ont fait de cette façon), auquel cas cela fonctionnerait sur n'importe quelle version de Java. (Oracle a décidé d'utiliser invokedynamic pour les lambdas pour la vérification future; peut-être qu'un jour JVM aura des fonctions de première classe, alors invokedynamic peut être changé pour les utiliser au lieu de générer une classe pour chaque lambda, améliorant ainsi les performances.) Ce que fait Retrolambda est qu'il traite toutes ces instructions dynamiques invoquées et les remplace par des classes anonymes; la même chose que ce que fait Java 8 lors de l'exécution lorsqu'un lamdba invokedynamic est appelé la première fois.
Répéter des annotations n'est que du sucre syntaxique. Ils sont compatibles avec le bytecode avec les versions précédentes. Dans Java 7, vous devez simplement implémenter vous-même les méthodes d'assistance (par exemple getAnnotationsByType ) qui cachent les détails d'implémentation d'une annotation de conteneur qui contient les annotations répétées.
AFAIK, les annotations de type n'existent qu'au moment de la compilation, elles ne devraient donc pas nécessiter de changements de bytecode, donc le simple fait de changer le numéro de version de bytecode des classes compilées Java 8 devrait être suffisant pour les faire fonctionner sur Java 7.
Les noms de paramètres de méthode existent dans le bytecode avec Java 7, donc c'est également compatible. Vous pouvez y accéder en lisant le bytecode de la méthode et en regardant les noms des variables locales dans les informations de débogage de la méthode. Par exemple, Spring Framework fait exactement cela pour implémenter @PathVariable , il existe donc probablement une méthode de bibliothèque que vous pouvez appeler. Étant donné que les méthodes d'interface abstraites n'ont pas de corps de méthode, ces informations de débogage n'existent pas pour les méthodes d'interface dans Java 7 et AFAIK non plus sur Java 8.
Les autres nouvelles fonctionnalités sont principalement de nouvelles API, des améliorations de HotSpot et des outils. Certaines des nouvelles API sont disponibles en tant que bibliothèques tierces (par exemple ThreeTen-Backport et streamsupport ).
En résumé, les méthodes par défaut nécessitent de nouvelles fonctionnalités JVM, mais les autres fonctionnalités linguistiques ne le sont pas. Si vous souhaitez les utiliser, vous devrez compiler le code en Java 8, puis transformer le bytecode avec Retrolambda au format Java 5/6/7. Au minimum, la version du bytecode doit être modifiée, et javac le désactive, -source 1.8 -target 1.7donc un rétrotranslateur est nécessaire.