RFR 8202913: loader constraint message for fields specifies incorrect referring class

[David Holmes]

On 26/05/2018 10:40 AM, David Holmes wrote:
> Hi Harold,
> 
> I don't think this was the minimal fix needed to address the missing 
> reference to the Child class, 

No I take that back. I messed up the original message in two ways and 
this addresses both of them. It's also more consistent with the method 
version. It also avoids confusing use of "referring class", by which I 
meant the current class that holds the putfield/getfield, not the REFC 
type of the putfield/getfield (which I just confused myself with!)

Thanks,
David
-----

> but these messages are so complicated and 
> unreadable now that I'm beyond trying to argue for their form.
> 
> I agree with Goetz about moving the tests to where the existing ones are.
> 
> Otherwise ok.
> 
> Thanks,
> David
> 
> On 25/05/2018 11:28 PM, Harold David Seigel wrote:
>> Hi,
>>
>> Please review this change to correct and simplify the error message 
>> displayed when a loader constraint check fails when trying to access a 
>> field.
>>
>> The old message (for this test case):
>>
>>       loader constraint violation: when resolving field "_field1" the
>>     class loader "<unnamed>" (instance of ClassLoaderForChildGrandFoo,
>>     child of "app" jdk.internal.loader.ClassLoaders$AppClassLoader) of
>>     the referring class, Parent, and the class loader "<unnamed>"
>>     (instance of ClassLoaderForParentFoo, child of "app"
>>     jdk.internal.loader.ClassLoaders$AppClassLoader) for the field's
>>     resolved type, Foo, have different Class objects for that type
>>
>> The new message:
>>
>>     loader constraint violation: when resolving field "_field1" of type
>>     Foo, the class loader "<unnamed>" (instance of
>>     ClassLoaderForChildGrandFoo, child of "app"
>>     jdk.internal.loader.ClassLoaders$AppClassLoader) of the current
>>     class, Child, and the class loader "<unnamed>" (instance of
>>     ClassLoaderForParentFoo, child of "app"
>>     jdk.internal.loader.ClassLoaders$AppClassLoader) for the field's
>>     defining type, Parent, have different Class objects for type Foo
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8202913/webrev/
>>
>> JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8202913
>>
>> This fix was tested with Mach5 tiers 1 and 2 tests and builds on 
>> Linux-X64, Windows, Solaris Sparc, and Mac OS X, with tiers 3-5 tests 
>> on Linux-x64, and with JCK-11 Lang and VM tests.
>>
>> Thanks, Harold
>>