@CallerSensitive as public API ?

[David M. Lloyd]

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 [1].
>
> Mandy
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018327.html
>> --
>> - 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:
>>>> 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
>>>
>


-- 
- DML