Alan, Was there a technical reason that the method was specified to fail when called from within the same thread ? Ie, is there a race condition or something similar that can happen, perhaps because the JVM relocates the stack ?
On Tue, Oct 29, 2019 at 12:26 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 23/10/2019 08:25, Alan Bateman wrote: > > > > Thread::countStackFrames has been deprecated for 20+ years and has > > been marked for-removal since Java SE 9. I'd like to remove it for > > Java SE 14. It's was never a well-defined method and I've been unable > > to find anything that uses it. The StackWalker API is a much better > > solution for code that is interested in the number of stack frames. > Joe Darcy has suggested degrading the method in advance of its removal. > We did the same with stop(Throwable) when we changed it to throw UOE in > Java SE 8 before finally removing it in 11. Here is the updated webrev > and CSR. The CSR will need to be re-reviewed. The method description is > brief and the same as what we did for stop(Throwable). > > http://cr.openjdk.java.net/~alanb/8205132/webrev.02/ > > https://bugs.openjdk.java.net/browse/JDK-8232654 > > Also just to summarize the discussion/objection from Seth Lytle. I think > we've established that that it was a regression in JDK 10 that allowed > that example to work. The method has always been specified to fail when > the thread is not suspended. > > -Alan > > >
