En tant que développeurs Java, nous avons tendance à fermer les yeux sur la mythique annotation @Deprecated, en continuant à utiliser des telles fonctionnalités tout en sachant pertinemment qu'Oracle pourrait les retirer à tout moment, et pourtant confiant en l'illusion qu'elles sont gravées dans la pierre.
Et bien Oracle déprécie (ou plus précisément supprime) une des méthodes ésotériques dans le package sun.reflect nommée Reflection.getCallerClass(int), et ils le font pour le jdk 7u40. Pour les versions de Java 7, vous pouvez toujours la récupérer en appelant Java avec l'option de ligne de commande -Djdk.reflect.allowGetCallerClass. Mais la méthode sera irrémédiablement supprimée à partir de Java 8. Une fois supprimée, l'appel à la méthode déclenchera une UnsupportedOperationException.
D'après la Javadoc), la méthode retourne la classe de la xème méthode de la pile d'appel, avec la class Reflection elle-même en position 0. En bref, la méthode getCallerClass fournit un mécanisme pour déterminer la classe appelante en vue d'implémenter un comportement "Appelant-dépendant", une méthode dont le comportement varie suivant la classe appelante ou suivant d'autres classes de la pile.
L'équipe du JDK aimerait connaître comment cette méthode est utilisée dans les applications et si le code incriminé peut être modifié pour être indépendant des API sun.*. Vous pouvez donner votre retour d'expérience directement en rejoignant la liste de diffusion core-dev-libs de l'OpenJDK.
Pour être juste, Oracle averti depuis des années les développeurs que l'appel de méthodes dans le package sun.* est périlleuse. Vous pouvez prendre connaissance des détails dans le blog d'Oracle "Pourquoi les développeurs ne doivent pas ecrire des programmes qui appelent les packages 'sun'". En bref, de telles fonctionnalités sont extrêmement fragiles et peuvent être déplacées, supprimées ou voir leur sémantique modifiée à tout moment et peuvent varier en fonction de la plateforme.
Si vous implémenter un comportement dépendant de l'appelant, tout n'est pas perdu. Il existe une Proposition d'Amélioration du JDK (JEP 176) qui demande une alternative pour "améliorer la sécurité de l'implémentation de gestion de méthodes du JDK en remplaçant la liste existante de méthodes dépendant de l'appelant réalisée manuellement par un mécanisme qui identifie précisément de telles méthodes et permet à leurs appelants d'être découverts de manière fiable".
Vous pouvez suivre le statut de cette demande en visitant la Base de Données de Bogues d'Oracle.