@CallerSensitive as public API ?

[David Lloyd]

I would say the opposite is true; the Class is safe but the ClassLoader is privileged.  Getting a ClassLoader from a Class requires a security permission when a security manager is present.

--
- DML


On Jun 25, 2013, at 8:57 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> 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
>