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

[Lois Foltan]

On 6/7/2018 5:54 AM, Lindenmaier, Goetz wrote:

> Hi Lois,
>
> any progress on this issue? I would like to still get this into jdk11 ...
Hi Goetz,

Yes, Mandy & I have made good progress on formulating a preliminary 
proposal consulting with Alex Buckley on suggested wording.  She will be 
sending that to you shortly.

Thanks,
Lois

>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: Lois Foltan [mailto:lois.foltan at oracle.com]
>> Sent: Freitag, 1. Juni 2018 15:26
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; mandy chung
>> <mandy.chung 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,
>>
>> Again, thank you for making the change to the IAE error message to
>> include the class loader name.  Due to the recommendation of differing
>> formats, we are discussing this internally to make sure the format we
>> suggest is a common format for not just IAE, but for all error messages
>> that may be changed in the future to include the class loader name.
>> Appreciate your patience with this and hopefully should have an agreed
>> upon proposal shortly.
>>
>> Thanks,
>> Lois
>>
>> On 5/25/2018 2:39 AM, Lindenmaier, Goetz wrote:
>>> Hi Mandy,
>>>
>>> thanks for looking at my change!
>>>
>>>>> I changed  the code as agreed:
>>>>> http://cr.openjdk.java.net/~goetz/wr18/8199940-exMsg-
>> IllegalAccess/02/
>>>>> The message is now:
>>>>> "class test.IAE1_B cannot access its superinterface test.IAE1_A"
>>>>> if there are no names in the loaders.
>>>> 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)
>>> Wouldn't it be better if we extend class_loader_and_module_name() to
>> print
>>> module at 0x3d04a311/test.IAE1_B if we pass a flag 'verbose' or the like?
>>> I think that is the  way Lois would prefer.
>>> If the modules differ, we could add some more text:
>>>
>>> "class module at 0x3d04a311/test.IAE1_B cannot access its superinterface
>> m1/test.IAE1_A because they are in different modules"
>>> One still would not know this was caused by using different loaders in the
>> implementation ...
>>>>> How should anybody know from the message that the classes were
>>>>> loaded by different loaders? It gives no hint at all to the cause of
>>>>> the problem.
>>>> 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)
>>> Hmm, as above, Lois wants me to use class_loader_and_module_name().
>>> Also, in none of my examples, modules have a name or are handled by
>>> the code in any way.  So it's quite misleading if the modules are reported
>>> as issue while it's in first place caused by the class loaders (which might
>>> induce modules that then cause the error.)
>>>
>>>> if the loader name is highly desirable (I'm unsure yet):
>>> Yes it is. It can be set by the developer and if he does so it should be
>> printed.
>>> The modules here seem to be generated automatically.  Maybe they
>> should
>>> derive their names from the class loaders if the relation between them is
>>> that obvious?
>>>
>>>> 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