RFR (S) 8023697: failed class resolution reports different class name in detail message for the , first and subsequent times

[Coleen Phillimore]

Thanks John,

On 5/5/14, 7:38 PM, John Rose wrote:
> The method handle bits look fine (essentially unchanged) to me.  Reviewed.

I do save the detailed message for method handle bits rather than having 
the rethrown message be "".  If you don't have a detail message, I saved 
the method handle name or method type signature.  I thought that would 
be useful.

> Saving the detail message, if already in the symbol table, is OK as modest increase in quality of service.
>
> I would like to see a clearer comment that we are doing more than the minimum requirements of the JVMS here.
>
> Otherwise, the next person to change this code will be puzzled about where is the spec. that the code meets.

I added this comment.

Thanks!
Coleen
>
> Suggest:
> -  // original error and throw it again (JVMS 5.4.3).
> +  // original error and detail message, and throw it again (JVMS 5.4.3).
> ++  // class of the original error and throw another error of the same class (JVMS 5.4.3).
> ++  // If there is a detail message, pass that detail message to the error constructor.
> ++  // The JVMS does not strictly require us to duplicate the same detail message,
> ++  // or any internal exception fields such as cause or stacktrace.  But since the
> ++  // detail message is often a class name or other literal string, we will repeat it if we
> ++  // can find it in the symbol table.
>
> I suspect this may cause trouble for somebody who tries to beautify detail messages
> in linkage errors.  A comment like the one above will lay out the relevant conditions.
>
> — John
>
> On Apr 28, 2014, at 5:39 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
>> Looks good to me but I’m not very familiar with that part of the code.
>>
>> On Apr 28, 2014, at 11:07 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>> Summary: Cache detail message when we cache exception for constant pool resolution.
>>>
>>> In the resolution error table.  Provide a default message if one is not in the original exception.  Also, consolidate duplicate code for MethodHandleInError and MethodTypeInError with UnresolvedClassInError.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8023697/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8023697
>>>
>>> Ran jck8, ute vm.quick.testlist, jtreg tests in hotspot/test, java/lang/invoke jdk jtreg tests.
>>>
>>> Thanks,
>>> Coleen