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

Nick Williams nicholas+openjdk at nicholaswilliams.net
Wed Sep 18 16:22:43 UTC 2013


Okay. Again, sorry for my absence. This wraps up my feedback for now. I now await responses from Mandy.

On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:

> On 9/17/13 10:32 AM, cowwoc wrote:
>> Hi,
>> 
>>    Has this been any new progress on this thread? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
>> 
> 
> I have sent my feedback a couple weeks ago on this proposed patch but haven't heard back from Nick.
> 
> You asked at a good time.  I discussed this with John Rose last couple days on this topic.  He has been thinking about how to do fillInStackTrace performantly and walk the stack with laziness and frame filtering.  The current implementation fills the entire stack trace while Groovy and Log4j use case filters the frames of some specific classes until it reaches the first one not being filtered.
> 
> He suggests to consider an API taking a callback shape (e.g. Function, Consumer, etc) that Remi Forax suggested at one time that allows the JVM to do something.   I will work with John to work out the details and determine the interface between VM and library and hash out issues.
> 
> I like the callback shape idea and hope to work out a proposal soon.
> 
>> I'd like to second Jörn concerns that shipping JDK8 (less than a month to go!) without a fix would be extremely problematic. The performance impact would be huge and the difficulty of introducing a change would be far more difficult than doing it before JDK8 is out.
>> 
>>    How do we go about moving this forward?
>> 
> 
> This RFE is target for JDK 8 and my priority to get that in.  I'm well aware the impact to Groovy and Log4j and some other existing applications that are seeking for a replacement of Reflection.getCallerClass.
> 
> Mandy
> 
> 
> 




More information about the core-libs-dev mailing list