Stack-Walking in Java With StackWalker and the Stream API

One of the coolest — and totally impractical —  features added to Java recently is the Stack-Walking API.

In this short article, we’ll check it out and see how surprisingly easy it is to use.

Stack-Walking Before Java 9

So far, the official solution was to obtain the current thread and call the  getStackTrace() method:

StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace();

The other smart solution involved included throwing an exception and extracting stack trace information from it. However, it wasn’t possible to manipulate the result; it would just get printed instantly:

new Exception().printStackTrace();

Both solutions suffer from the same problem — they eagerly capture a snapshot of the entire stack and aren’t handy to use.

JEP-259: Stack-Walking API

JEP-259 was supposed to address those problems, and it did. The new API provides a handy way of traversing stack traces lazily using Stream API.

We can create a StackWalker instance as easily as:

StackWalker stack = StackWalker.getInstance();

Additionally, we can provide some initial options:

StackWalker stack = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

And, if we want to traverse the whole stack, it’s simply a matter of calling the forEach() method:

stack.forEach(System.out::println);

StackWalker.StackFrame

If we look at the Java 1.4’s StackTraceElement, it’s pretty much a DTO containing String information about a declaring class, method name, classloader name, etc.

 StackWalker.StackFrame is a much more type-safe-friendly upgrade that is enriched with methods like:

public Class<?> getDeclaringClass();

public MethodType getMethodType();

And, even:

public StackTraceElement toStackTraceElement();

This is the case if we missed the legacy format.

Example

Let’s put that into action and create a simple call hierarchy:

public static void main(String[] args) {
    foo();
}

private static void foo() {
    bar();
}

private static void bar() {
    java.lang.StackWalker
      .getInstance(java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE)
      .forEach(System.out::println);
}

And, if we run it, the result will look like the following — notice the order of the stack elements:

com.pivovarit.stack.StackWalker.bar(StackWalker.java:16)
com.pivovarit.stack.StackWalker.foo(StackWalker.java:10)
com.pivovarit.stack.StackWalker.main(StackWalker.java:6)

Advanced Features

If we want to leverage laziness or frame filtering, we can use the other dedicated API method called walk() that allows us to use the Stream API to conveniently traverse the stack. While reading this, you probably imagined the walk() method to simply return a Stream instance. Well, this is not the case.

The actual signature is:

public <T> T walk(Function<? super Stream<StackFrame>, ? extends T> function)

And, there’s a good reason for it to be this way — the stack needs to be frozen for it to be traversed, and this happens within the scope of the walk() method call, so it makes sense to utilize the functional-interface-based template method implementation to achieve that.

Even if you try to trick it by returning a Stream instance, it won’t be usable. You can try it yourself if you don't believe me!

Once we know that limitation, we’re only bound by our imagination and the Stream API capabilities. For example, we can gracefully skip some frames and pick the first encountered one:

java.lang.StackWalker
  .getInstance(java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE)
  .walk(s -> s.skip(1).limit(1).collect(Collectors.toList()))
  .forEach(System.out::println);

// result
com.pivovarit.stack.StackWalker.foo(StackWalker.java:12)