Review Request JDK-8186050: StackFrame should provide the method signature
Peter Levart
peter.levart at gmail.com
Fri Sep 22 10:45:32 UTC 2017
Hi Mandy,
On 09/21/2017 05:15 PM, mandy chung wrote:
> 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.
Ok, I buy it.
>>
>> 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
Just two more things...
1st:
I was I little confused reading this part of javadoc of getDescriptor():
152 * Returns the <i>descriptor</i> of the method type for
153 * this stack frame. A method descriptor is a string
representing the
154 * types of parameters that the method takes, and a return
descriptor,
155 * representing the type of the value (if any) that the
method returns
156 * as defined by <cite>The Java™ Virtual Machine
Specification</cite>.
Wouldn't it be better to say:
152 * Returns the <i>descriptor</i> of the method type for
153 * this stack frame. A method descriptor is a string
representing the
154 * types of parameters that the method takes, and the
method's return type,
156 * as defined by <cite>The Java™ Virtual Machine
Specification</cite>.
I think there is a slight difference between "method return type" and
"the type of value (if any) that the method returns". The former is a
property of the method, the later is a property of the returned value
(primitive or reference or none) in a particular invocation of the
method and may be different (a subtype).
2nd:
I don't know in what circumstance may the MemberName.getMethodType() or
.getMethodDescriptor() return null, but the MemberName code is written
as follows:
169 if (type == null) {
170 expandFromVM();
171 if (type == null) {
172 return null;
173 }
174 }
Is there a real circumstance when this may happen? Should
StackWalker.StackFrame.getMethodType() / .getDescriptor() document that
situation or maybe transform it into an exception or error?
Regards, Peter
More information about the core-libs-dev
mailing list