RFR(M): 8199940: Print more information about class loaders in IllegalAccessErrors.

[mandy chung]

On 6/19/18 6:58 AM, Lindenmaier, Goetz wrote:
> Hi,
> 
> I implemented what Mandy suggested:
> http://cr.openjdk.java.net/~goetz/wr18/8199940-exMsg-IllegalAccess/03/
> 
> For this format, I could imagine following simplification of the expression in brackets:
> 
> If both loaders are the same
>      If loader1 is well known
>          print nothing

What is a well known loader?  Are you referring to the built-in loaders?

Mandy

>     else
>          print "(in loader test.IAE_Loader1 @id)"
>    fi
> else
>     print  "(test.IAE1_B is in loader test.IAE_Loader1 @id; test.IAE1_A is in loader 'app')"
> fi
> 
> ... I would need to improve my tests ...
> Maybe a follow up after JDK-8169559?
> 
> Best regards,
>    Goetz.
> 
> 
> 
>> -----Original Message-----
>> From: mandy chung [mailto:mandy.chung at oracle.com]
>> Sent: Montag, 18. Juni 2018 21:24
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; 'Lois Foltan'
>> <lois.foltan at oracle.com>
>> Cc: hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8199940: Print more information about class loaders in
>> IllegalAccessErrors.
>>
>> Hi Goetz,
>>
>> Lois, Harold, and I discussed briefly how to help this patch move
>> forward independent of JDK-8169559 (that intends to replace
>> Klass::class_loader_and_module_name with a better utility method).
>>
>> The format we propose is to change from:
>>     $C1 cannot access its superinterface $C2
>>
>> TO:
>>     $C1 cannot access its superinterface $C2 ($C1 is in $M1 of loader
>> $L1; $C2 is in $M2 of loader $L2)
>>
>> The above will depend on JDK-8169559.
>>
>> The intermediate step is for JDK-8199940 to append the loader info in IAE:
>>    $C1 cannot access its superinterface $C2 ($C1 is in loader $L1; $C2 is
>> in loader $L2)
>>
>> This will depend on the new loader_name_and_id function introduced by
>> JDK-8202605. JDK-8169559 can add the module info in the exception
>> messages as a follow-up issue (these IAEs don't have any module info in
>> the current implementation anyway.)
>>
>> For IAE in member access, I suggest to rephrase the message from:
>>
>> tried to access method test.IllegalAccessErrorTest.iae4_m()V from class
>> test.Runner4
>>
>> TO:
>>
>> class test.Runner4 tried to access private method
>> test.IllegalAccessErrorTest.iae4_m()V (test.Runner4  is in loader 'app';
>> test.IllegalAccessErrorTest. is in loader 'app')
>>
>> What do you think?
>> Mandy
>>
>> On 5/24/18 3:15 PM, mandy chung wrote:
>>>
>>>
>>> On 5/24/18 2:12 PM, Lindenmaier, Goetz wrote:
>>>> Hi Lois,
>>>>
>>>> I changed  the code as agreed:
>>>> http://cr.openjdk.java.net/~goetz/wr18/8199940-exMsg-
>> IllegalAccess/02/
>> :
>>
>>> For this IAE, it should include the module in the message as:
>>>
>>> class test.IAE1_B (in unnamed module @0x3d04a311) cannot access its
>>> superinterface test.IAE1_A (in module m1)
>>>
>>> The above is one example that does not have the loader name.
>>> Each module is defined to one loader so it can derive from
>>> the module info.
>>>
>>>>> java.lang.IllegalAccessError: tried to access private method
>>>>> MySameClassLoader/m2x/p2.c2.method2()V from class
>>>>> MySameClassLoader/m1x/p1.c1
>>>
>>> What about other formats:
>>>
>>> tried to access private method p2.c2.method2()V (in module m2x) from
>>> class p1.c1 (in module m1x)
>>>
>>> if the loader name is highly desirable (I'm unsure yet):
>>>
>>> tried to access private method p2.c2.method2()V (in module m2x defined
>>> to MySameClassLoader) from class p1.c1 (in module m1x defined to
>>> MySameClassLoader)
>>>
>>> Mandy