BT

Oracle Discontinuing sun.reflect.Reflection.getCallerClass

by Victor Grazi on Jul 03, 2013 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Why is this method being discontinued? by Victor Grazi

Does anyone know why Oracle is pulling the plug on this method? It seems like a pretty neat way to investigate the call stack!

Re: Why is this method being discontinued? by Vikram Gupta

The unofficial reason circulating is that being a sun.* method, it is for internal use only, and it is no longer being called internally by any class in the OpenJDK 7 or 8. You can find more info in JEP 176. It would be interesting to learn if there are any popular frameworks that make use of this method, that might be affected.

Re: Why is this method being discontinued? by Conny Kreyßel

For me, the implementation of getCallerClass() of the javacpp project (code.google.com/p/javacpp/source/browse/src/mai...) is a good option.

It does not use any sun.* classes.

Changes to this method in JDK7u25 have broken Grails by Dean Schulze

Re: Why is this method being discontinued? by Vikram Gupta

Well, this almost always will work, except in cases where you have different versions of the same class name loaded with different class loaders.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT