@CallerSensitive as public API ?

[Peter Levart]

On 06/25/2013 09:24 PM, Mandy Chung wrote:
>> 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)...
>
> Besides providing a method returning the caller's class, I'd like to 
> consider what other options we have and different use cases could be 
> satisfied by different API.  For #2, the problem is that the API to 
> find a resource, it requires to use the ClassLoader with the right 
> visibility (the caller's class loader).  This is similiar to 8013839 : 
> Enhance Logger API for handling of resource bundles [1].  For example, 
> a static method Class.getResource to use the caller's class loader to 
> find the given resource might be an alternative?

Might be enough sometimes, but usually the ClassLoader is not enough, 
since the location of resources (resource path) might be determined by 
caller's class name or package (relative to caller's class, for 
example). So perhaps, if j.l.Class object is to security sensitive, a 
tuple (caller ClassLoader, caller class name) might be enough for #2 usages.

Regards, Peter