@CallerSensitive as public API ?
David M. Lloyd
dlloyd at redhat.com
Tue Jul 2 13:55:15 UTC 2013
On 6/25/13 5:42 PM, Mandy Chung wrote:
> On 6/25/13 3:04 PM, David Lloyd wrote:
>> 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?
> Which frame do you need? How do you use it?
Typically it's the frame belonging to whomever called the method on the
class. So it's not a search situation, it's a constant offset.
>> As an aside, getClassContext returns a Class; maybe it should be
>> changed to Class<?> instead.
> Ah. I can fix that in my fix for 8007035 .
>> - DML
>> On Jun 25, 2013, at 8:35 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> On 6/25/13 3:50 AM, Peter Levart wrote:
>>>> 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 . 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  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.
>>>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
More information about the core-libs-dev