@CallerSensitive as public API ?

Mandy Chung mandy.chung at oracle.com
Sat Jul 20 01:41:57 UTC 2013


FYI.  I have filed this RFE:
    8020968: Load resource files using the caller's class and class loader


On 6/25/2013 6:50 PM, Peter Levart wrote:
> Hi,
> 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