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

Jochen Theodorou blackdrag at gmx.org
Fri Sep 20 08:57:47 UTC 2013


Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
> This is all well and good, but some of us just need a simple array. This seems like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.

if you need the full stack, then misusing a Predicate and a dummy 
Consumer to collect everything looks a lot like not intended use. The 
intended inability of lambdas to write to local variables outside the 
lambda is not helping here to avoid anonymous inner classes. So what was 
a simple method call, will look really awful - I agree. But if you would 
have designed the API that uses the information now, rather than fitting 
the old API from the frame work and the new API here together, then this 
problem would most probably not have appeared, since the structure would 
have been very different from the beginning.

>> I have modified java.util.logging.LogRecord to infer the caller using the new API (much simpler):
>>
>>     StackTraceElement frame =
>>         Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },
>>                            StackFrameInfo::stackTraceElement);
>>
>> Replacement for getCallerClass()
>>     Class<?> c = Thread.getCaller(StackFrameInfo::getDeclaringClass);
>>
>> Replacement for traversing the stack with getCallerClass(int depth)
>>     Thread.walkStack(e -> doSomething(e));
>
> This looks beautiful for Java 8, sure. Now try doing these same things in a library compiled for Java 6 but made to be compatible with Java 8 and so all of this has to happen via reflection. Suddenly it's nightmarish.

With a new class to contain the information it will look like a 
nightmare even if you get an array and do not have that callback style. 
What we will probably do is a kind of plugin that gets enabled if jdk8 
is used. That class will have to be compiled using jdk8 though. And in 
case of an older jdk the old implementation will be used

bye Jochen


-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org




More information about the core-libs-dev mailing list