Proposed API for JEP 259: Stack-Walking API

Timo Kinnunen timo.kinnunen at
Fri Nov 20 03:37:38 UTC 2015

The issue is that usually IllegalStateException implies the callee went into the wrong state thanks to what the user has done; as nothing happens until a user puts things in motion by executing some code. But this is not the case here. In this case the IllegalStateException only reflects an implementation detail that might change in the future. Any decision from a user on seeing an ISE here can only bring about extra dependencies on this in ways throwing an UnsupportedOperationException wouldn’t.

Sent from Mail for Windows 10

From: David Holmes
Sent: Friday, November 20, 2015 03:12
To: Timo Kinnunen;John Rose
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack-Walking API

On 19/11/2015 11:36 PM, Timo Kinnunen wrote:
> A point in favor of UnsupportedOperationException would be: if in the
> future it becomes possible to have large parts of the JVM written in
> Java or becomes part of the J2SE API then having an instance
> of a VirtualMachine class as the caller of public static void main and
> could be completely true and natural. Changing getCallerClass
> to support this and not throw an UOE feels less of a breaking change
> than it no longer throwing an IllegalStateException. Especially since no
> state that the caller can affect has actually changed!

@throws IllegalStateException if called from a context where this is no 
Java caller present

If you change the VM implementation so there is a Java caller then you 
don't throw ISE any more. I don't see any issue.


> Sent from Mail <> for
> Windows 10
> *From: *John Rose
> *Sent: *Thursday, November 19, 2015 05:45
> *To: *David Holmes
> *Cc: *OpenJDK Dev list
> *Subject: *Re: Proposed API for JEP 259: Stack-Walking API
> On Nov 18, 2015, at 6:32 PM, David Holmes <david.holmes at> wrote:
>  >
>  >>>
>  >>> Looks good to me too if IllegalStateException is used instead of
>  >>> UnsupportedOperationException.
>  >>> UnsuppportedOperationException is used when the operation is not
>  >>> available, here, the same code can work or not depending how it is
>  >>> called.
>  >>
>  >> But IllegalStateException is dependent on some state. There's no state
>  >> involved here (in the sense "state" is characterized in Java). My 1st
>  >
>  > I agree with Remi. "state" doesn't have to mean fields - there are
> numerous existing examples in the JDK. Calling a method in a context
> that is invalid is an illegal state to me. IllegalThreadStateException
> would also work. But UnsupportedOperationException ... more of a stretch.
> +1

More information about the core-libs-dev mailing list