Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Oracle Discontinuing sun.reflect.Reflection.getCallerClass

Oracle Discontinuing sun.reflect.Reflection.getCallerClass

Lire ce contenu en français

As Java developers we tend to close an eye to the proverbial @Deprecated annotation, continuing to use such features knowing full well that Oracle could pull the plug at any time, yet confident in the illusion that these are indelibly etched in stone.

Well Oracle is deprecating (as in eliminating) one esoteric method under the sun.reflect package called Reflection.getCallerClass(int), and they are doing so as of jdk 7u40. For Java 7 versions you can still get it back by calling Java with the command line option -Djdk.reflect.allowGetCallerClass. But the method will be completely removed as of Java 8 and beyond. Once removed a call to the method would trigger an UnsupportedOperationException.

According to the Javadoc the method returns the class of the method x frames up the call stack, with the Reflect class itself at position 0. In short, the getCallerClass method provides a mechanism for determining a caller's class in order to implement "Caller Sensitive" behavior, a method which varies its behavior based on the calling class or other classes in the call stack.

The JDK team would like to know how this method is being used in applications and whether such code can be modified without any dependency on sun.* API's. You can provide feedback directly by joining the OpenJDK core-dev-libs mailing list.

To be fair, Oracle has advised developers for years that calling methods under the sun.* packages is "risky business". You can read the specifics in the Oracle blog entry "Why Developers Should Not Write Programs That Call 'sun' Packages". In short, such features are highly brittle and may be moved, removed, or semantically altered at any time and may vary from platform to platform.

If you are implementing caller sensitive behavior all is not lost. There is a JDK Enhancement-Proposal (JEP 176) calling for an alternative way to "improve the security of the JDK’s method-handle implementation by replacing the existing hand-maintained list of caller-sensitive methods with a mechanism that accurately identifies such methods and allows their callers to be discovered reliably."

You can keep track of the status of this issue by visiting the Oracle Bug Database.

Rate this Article