@CallerSensitive as public API ?

[Mandy Chung]

Peter,

FYI.  I have filed this RFE:
    8020968: Load resource files using the caller's class and class loader
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020968

Mandy

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
>