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

[Peter Levart]

On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
> Am 20.09.2013 11:34, schrieb Peter Levart:
> [...]
>> List<StackFrameInfo> frames = new ArrayList<>();
>> Thread.walkStack(frames::add);
>>
>> No so awfull.
>
> as I said, it is unclear to me as of if walkStack walks the whole 
> stack or not. Your code implies it does. If It does, I don't see the 
> advantage of suing a Stream here.... or does the predicate version not?

Right.

I think the reasoning behind call-back API is that it moves the logic to 
construct a suitable data structure to the Java side, skipping 
intermediary representations and conversions. I don't know what the 
overhead of call-backs from native code to Java is though. For 
constructing and returning an array of StackFrameInfo objects, the 
native code has to collect the objects into a GrowableArray (a native 
equivalent of ArrayList). Before returning, it has to copy elements into 
the Java array. And this Java array is usually later used just to 
iterate it's elements... Imagine a situation where GrowableArray and 
Java array could be skipped and StackFrameInfo objects directly 
formatted into a StringBuilder, creating the final logger message. This 
assumes that call-backs from native code are cheap. Are they? Can native 
method be intrinsified together with call-back invocations?

To support this call-back API in a JDK6 compatible way, but optimally, I 
would create a similar API to the one in JDK8 in the form of interfaces 
and then provide two implementations:
- the JDK8 implementation: a thin wrapper over JDK8 API
- the JDK6/7 implementation: an emulation adapter using JDK6/7 provided APIs

Regards, Peter

>
> bye blackdrag
>