RFR (S) 8023697: failed class resolution reports different class name in detail message for the , first and subsequent times
coleen.phillimore at oracle.com
Mon May 5 23:57:44 UTC 2014
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
> 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.
> - // 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.
More information about the hotspot-runtime-dev