On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
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.
List<StackFrameInfo> frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
Regards, Peter
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
