JDK-8212620 : Provide a mechanism to allow a class/method to request filtering from the stack trace
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-10-17
  • Updated: 2021-10-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8243287 - Removal of Unsafe::defineAnonymousClass
Relates :  
JDK-8171335 - MethodHandle.Lookup functionality to define a nestmate class
Relates :  
JDK-8213234 - Move LambdaForm.Hidden to jdk.internal.vm.annotation
Relates :  
JDK-8025636 - Hide lambda proxy frames in stacktraces
Relates :  
JDK-8268526 - Lambdas are hidden inconsistently in stack traces.
Description
It'd be useful to provide a mechanism for a class/method to request filtering from stack trace. 

For example, lambda proxy classes are implementation details.  Showing it in the stack trace does not provide useful information while it makes the stack trace longer.    Reflection implementation classes are good candidate to be filtered as well.  VM has special handling of @java.lang.invoke.LambdaForm.Hidden annotation and also skip reflection frames to find the caller of @CS method. 
java.lang.Throwable
     StackTraceTest.lambda$0(StackTraceTest.java:6)
     StackTraceTest$$Lambda$1.run(Unknown Source)
     StackTraceTest.main(StackTraceTest.java:8)
Comments
For Nashorn to use hidden classes, it needs a way to define a hidden class without hiding their frames. See more https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html A similar request from Apache Lucene: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068542.html
20-10-2021
In the context of JDK-8268526 I think there should be a difference between exception stack trace reporting (which this RFE seems to be about) and Thread stack trace reporting. Implementation frames in an exception stacktrace are noise if the exception did not originate there. But for a thread stacktrace you generally want to see the actual stacktrace. In relation to this RFE, if the exception is raised outside of platform library code, then perhaps the backtrace can hide system frames by default. Though it gets tricky if there are secondary exceptions due to catch/finally blocks that execute in response to the original exception.
14-06-2021
Hidden classes are added in JDK 15. They are hidden from stack trace by default. There are requests to make them visible.
19-10-2020
I think we are talking about at least 3 different things here: 1 - ignoring call stack frames for @CS methods to work properly 2 - filtering call stack frames that nobody wants to see in the stack traces (like lambda proxy methods) 3 - filtering call stack frames that some users don't want to bother with For the 3rd category, some might not be interested in frames not belonging to code they are maintaining/debugging but others might be. In above example, a developer of the Stream API implementation will be left without stack trace frames important for her/him, if they were filtered-out. So the idea of filtering out the frames at print time for this 3rd category is perhaps a good one. For 2nd and 3rd category when an exception is thrown from a method that would be filtered out, at least that starting frame should be printed nevertheless.
09-09-2020
Ok, got it :) i wonder if it's no better to do not change the way stack elements are collected but only change the way stacktrace are printed
23-10-2018
All stack trace related API will need to be considered. Indeed, this RFE is motivated by providing a standard replacement for @Lambda.Hidden.
23-10-2018
yes, but i think we should not just allow to hide a method but a range of subsequent method, something saying hide the current stack element and all the subsequent elements that are in the same class, same package or even same module. I has the potential of changing the live to a lot of Java EE/container users by drastically reduce the stacktrace by hiding implementation details (again if no exception occurs in the stack element range and if the user can see that the stack elements have been collaped). I also wonder if it's not more that the default printStackTrace that should not print the stack element even if the stack trace is itself unmodified so people can choose if they want the full stacktrace to be printed or only the Also note that there is already an annotation in java.lang.invoke (@LambdaForm.Hidden) that allows to hide a stack element.
23-10-2018
Remi, thanks for the sample stack trace. If there is a way to mark a class to be hidden from backtrace, the stream machinery can use such mechanism and the stack trace provided e.g. from an exception would be compact and more user-friendly
23-10-2018
A code like this: static String identity(String x) { throw new NullPointerException(); } public static void main(String[] args) { List.of("foo", "bar") .stream() .map(s -> identity(s)) .forEach(System.out::println); } creates this stack trace Exception in thread "main" java.lang.NullPointerException at StreamTooMuchGarbage.identity(StreamTooMuchGarbage.java:5) at StreamTooMuchGarbage.lambda$0(StreamTooMuchGarbage.java:11) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(AbstractList.java:720) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) at StreamTooMuchGarbage.main(StreamTooMuchGarbage.java:12) All the methods inside the stream implementation are not useful at least if there is no exception inside the implementation itself, a stacktrace like this is as useful Exception in thread "main" java.lang.NullPointerException at StreamTooMuchGarbage.identity(StreamTooMuchGarbage.java:5) at StreamTooMuchGarbage.lambda$0(StreamTooMuchGarbage.java:11) at ... <--- something that shows that the stack frame are not shown because they are not useful at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) at StreamTooMuchGarbage.main(StreamTooMuchGarbage.java:12)
23-10-2018
[~forax] do you have an example of the use of Stream API you described?
23-10-2018
In my opinion, the biggest offender currently is the Stream implementation to the point i don't use the Stream API if the stream has a virtual call to a method i don't control. Which is a kind of shame.
17-10-2018