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 >
