@CallerSensitive as public API ?
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)...
More information about the core-libs-dev