On 20. September 2013 at 11:03:49, Jochen Theodorou (blackd...@gmx.org) 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.
+1
> 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.
Joern
