We have a use case within our security manager implementation that *can* be 
solved with the existing getClassContext method, which returns the whole stack, 
except we don't *need*  the whole stack, just one specific frame.  Maybe 
SecurityManager is a good place for this API?

As an aside, getClassContext returns a Class[]; maybe it should be changed to 
Class<?>[] instead.

--
- DML


On Jun 25, 2013, at 8:35 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:

> On 6/25/13 3:50 AM, 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.
> 
> It's good to know these use cases.  We leave the method in 7 update release 
> so as to allow time for applications to transition and also determine any use 
> case that the SE API should provide if there is no replacement for it.
> 
>> 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?
> 
> About the timeframe, the API freeze date [2] is Oct 10.  If the API is simple 
> and small effort (test development, security assessement, etc), there is 
> chance to get that in for jdk8.
> 
> Mandy
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
> [2] http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze
> 

Reply via email to