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

Jörn Huxhorn jhuxhorn at
Fri Sep 20 09:31:04 UTC 2013

On 20. September 2013 at 11:03:49, Jochen Theodorou (blackdrag at wrote:
Am 20.09.2013 10:50, schrieb Jörn Huxhorn: 
> But I have serious doubts that *this* is going to be more efficient than just iterating over an array. 


> Feel free to add all that functionality but all we are asking for right now is access to the call stack array in a way that is as fast, or, ideally, even faster than using the current getCallerClass(int) method. Performance is the main reason for this whole discussion. 

when it comes to getCallerClass(int) I see need for improvement in the 
API. But I see the patch as a draft only 

> And it is very, very crucial that all of this can be done via (Java 6) reflection so that code will be able to use sun.reflect.Reflection up to J7 and the new API after that... 

you mean you want to use the new API via Java6 reflection? Then there 
should be no new class to be used. Otherwise you will get crazy with 
writing out all the reflective calls. I think it is better to go with a 
plugin-like structure and write code for the new API with JDK8. I am of 
course aware, that this makes the build more complicated 
I mean that it must be possible to handle the call by means of simple <= JDK1.5 Class.forName("StackTraceFrame") and clazz.getMethod(..) and method.invoke(..).

That way, the only thing to care about is a ClassNotFoundException and the "method" could be kept for any future calls. The class file responsible for the call should be able to have 49.0 or 50.0 since handling a ClassNotFoundException is less hardcore than catching a UnsupportedClassVersionError.

I'd consider a jar file containing files with more than one java class version way more brittle than any alternative.


More information about the core-libs-dev mailing list