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

[John Rose]

The method handle bits look fine (essentially unchanged) to me.  Reviewed.

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.

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
>