@CallerSensitive as public API ?

[Mandy Chung]

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