[ping] RFR(L): 8221470: Print methods in exception messages in java-like Syntax.

[David Holmes]

On 1/04/2019 6:02 pm, Lindenmaier, Goetz wrote:
> Hi David,
> 
>> I'm looking at this ...
> Great, thanks!
> 
>> I'm personally of two minds here because these VM generated exceptions
>> are not only delivered to Java source code. I'd like to know how other
>> language developers using the JVM runtime would view this.
> I thought about the other languages, too. But then I think why would the
> one be better than the other, if they don't reflect the actual
> code of that language?

"VM language" is at least a "common denminator".

>> That aside if you're going to make a change like this then I think the
>> full signature string has to be quoted in some way to delineate it
>> within the larger message.
> Quoting would especially help because of the space between return
> type and the method name. It would be easier to capture that they
> belong together.
> But for consistency, we should then quote all class, field and method
> names, which is currently not the case as you can easily see by looking
> at the updated messages in the tests.

It's mainly the spaces caused by return types that is the issue so I 
don't see we need to quote everything to address that issue.

David
-----

> I thought about leaving out the return type, but that would mean to
> drop important information.
> So I'm not sure here ...
> 
> Best regards,
>    Goetz.
> 
>   
>>> Should I split it to adapt the exceptions separately one-by-one to
>>> make the change smaller and simplify the review?
>>
>> I don't think that is necessary.
>>
>> Thanks,
>> David
>> -----
>>
>>> I would propose to start out with AbstractMethodError only.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>> From: Lindenmaier, Goetz
>>> Sent: Tuesday, March 26, 2019 1:06 PM
>>> To: hotspot-runtime-dev at openjdk.java.net
>>> Subject: RFR(L): 8221470: Print methods in exception messages in java-like
>> Syntax.
>>>
>>> Hi,
>>>
>>> A row of exceptions are thrown from the hotspot runtime.
>>> They print methods with their JNI signatures. To increase
>>> readability and resemblance to source code, this change proposes
>>> to print them in a Java-like syntax.
>>>
>>> Some examples:
>>> current method printouts:
>>>
>>> test.TeMe3_B.ma()V
>>> test.TeMe3_B.ma(IZ[[BF)[[D
>>> test.TeMe3_B.ma([[[Ljava/lang/Object;)[[Ltest/TeMe3_B;
>>>
>>> improved format:
>>>
>>> void test.TeMe3_B.ma()
>>> double[][] test.TeMe3_B.ma(int, boolean, byte[][], float)
>>> test.TeMe3_B[][] test.TeMe3_B.ma(java.lang.Object[][][])
>>>
>>> So far, Method::name_and_sig_as_C_string() is used to print
>>> these messages.
>>>
>>> This change implements function Method::external_name() that prints the
>> better
>>> format.
>>> external_name() is chosen according to Klass::external_name().
>>>
>>> Printing the better format requires parsing the signature
>>> Symbol. This is implemented in
>>> void Symbol::print_as_signature_external_return_type(outputStream *os);
>>> void Symbol::print_as_signature_external_parameters(outputStream *os);
>>> These method names are chosen according to
>> Symbol::as_class_external_name().
>>>
>>> See this partial webrev for the new functions:
>>> http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/01-
>> new_methods/
>>>
>>> Also, I changed a lot of exception messages to use the new format.
>>> This required to adapt a row of tests. I added a test to check
>>> the signature printing does not regress.  For all these changes, see
>>> the full webrev:
>>> http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/01/
>>>
>>> I hope I detected all places where method signatures are printed to
>>> exception messages.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>