@CallerSensitive as public API ?

Peter Levart peter.levart at gmail.com
Tue Jun 25 10:50:55 UTC 2013


I know that @CallerSensitive annotation was introduced to bring some 
order to JDK internal plumbings. It's scope was to support JDK internal 
usage, so it's use is limited to classes loaded by bootstrap or 
extension class-loaders. In JDK-internal code it is used mainly for 
implementing security-sensitive decisions. But since the 
sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, 
it found it's way out into user code, where at least I know that it is 
used in two areas:

1 - to locate callers in the whole call-stack so that their location in 
class-path can be reported (Log4J is an example)
2 - to locate immediate caller so that some resources associated with it 
can be located and used (for example localization data in GUI applications)

I don't know how wide-spread 1st usecase is, but the 2nd is common, 
since it's use enables APIs that need not explicitly pass-in the calling 
class in order to locate resources associated with it (and/or the 
class-loader of it). So it would be nice to have such supported API in 
JDK8 at least.

I'm asking here, to hear any arguments against making such API supported 
and public. Are there any security or other issues? If there aren't, 
what steps should be taken to introduce such API in the JDK8 timeframe? 
I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving 
@CallerSensitive to a supported package + enabling it to mark methods in 
any class (not just system and ext classes)...

Regards, Peter

More information about the core-libs-dev mailing list