[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[David M. Lloyd]

On 09/08/2013 09:34 PM, Mandy Chung wrote:
>
> On 9/4/2013 6:02 PM, David M. Lloyd wrote:
>>
>> This seems reasonable on the surface but falls over once you capture
>> the caller for more than one purpose.  For example, say a logging
>> framework captures the caller for the purpose of supplementing log
>> information. But you call this logging framework from another
>> framework which uses caller information for another purpose, for
>> example locating resources.  The intent here might be to show
>> information from the second framework in the log, however with one
>> universal @CallerSensitive annotation you cannot distinguish which
>> "capture" you want to grab - the second framework, or the caller who
>> called the second framework.  However by traversing the stack to a
>> fixed depth, you can do so very definitively (as long as you always
>> know that your internal code does *not* directly call the sensitive
>> method - an easy thing to design for in most frameworks).
>>
>
>
> It would need to detect if the intermediate frames don't call any
> "sensitive" method.
>
> @sun.reflect.CallerSensitive is primarily defined for the security issue
> and specifically for JEP 176.  As you said, the current form of @CS
> doesn't satisfy other purposes.
>
>> In fact you can usually traverse the stack to a fixed depth for this
>> kind of thing, with one key exception that comes up in log frameworks.
>> When you have one log API which forwards to another, you want to
>> capture the "first" caller of any log API.  Pursuant to this, most log
>> frameworks have log method variants which accept the fully-qualified
>> class name of that first logger.  The moral equivalent to this
>> scenario would likely be to provide an API variant which accepts a
>> Class or ClassLoader (depending on the usage) and a variant which does
>> not and uses a fixed-depth "reach" into the stack instead.
>> This IMO blows a hole in the whole idea of a single *public* @CS
>> annotation, and in fact in public framework code, a depth indicator
>> seems to be adequate and more or less problem-free for any purpose
>> I've run across.
>
>
> I'm not sure if we can be very certain about the depth in a runtime
> environment (non-debugging) unless it requires all VM implementation to
> support a reliable way to return a frame at a given depth.
>
> The stack trace is not guaranteed to contain all stack frames. E.g. in
> the spec of Throwable.getStackTrace():
>
>     Some virtual machines may, under some circumstances, omit one or more
>     stack frames from the stack trace. In the extreme case, a virtual
> machine
>     that has no stack trace information concerning this throwable is
>     permitted to return a zero-length array from this method.

This is interesting.  Presumably this would tie into tail-call 
optimizations and that sort of thing?

How does AccessControlContext deal with this possibility?


-- 
- DML