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

[Harold David Seigel]

Hi David,

Thanks for the review!

Harold

On 5/25/2018 8:57 PM, David Holmes wrote:
> 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
>>>