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.lev...@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 >
