Proposed API for JEP 259: Stack-Walking API

[David Holmes]

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 sun.tools becomes part of the J2SE API then having an instance
> of a VirtualMachine class as the caller of public static void main and
> Thread.run 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.

Cheers,
David

> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> 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 oracle.com> 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
>