Hi Peter,
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186050/webrev.03/
On 9/3/17 7:02 AM, Peter Levart wrote:
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186050/webrev.02/
That's what I had in mind, yes.
Looking at the method names, I have a second thought about the too
general StackFrame::getDescriptor(). Not looking at the javadocs, one
could ask: "what is a descriptor of a stack frame?". I don't know,
maybe getMethodDescriptor() would be more to the point or even
getMethodTypeDescriptor() (since it is a descriptor of method
parameter and return types, not containing method name). What do you
and others think?
Descriptor is specified in JVMS 4.3:
A /descriptor/ is a string representing the type of a field or method.
I initially had getMethodDescriptor() while "Method" is kinda redundant
since StackFrame represents a method invocation. Descriptor in this
context is for a method and never be a field. Hence I like Remi's
suggestion to rename it to getDescriptor.
Although it is not expected for StackFrame interface to be implemented
by custom classes, it is a public interface. I have seen 3rd party
code implementing JDK interface that was not meant to be implemented
by custom classes just because the interface seemed appropriate. To
keep binary compatibility with such potential implementations, those
two new methods could be default methods throwing UOE.
Having a second thought, while it's rarely to have custom StackFrame
implementation, I agree making the new methods to be default method that
would help migration for tests or other use.
nit: while you are at it, you could remove the redundant "static"
modifier from the StackWalker.StackFrame interface declaration.
Done
Mandy
