RFR(M): 8199852: Print more information about class loaders in LinkageErrors.

Lois Foltan lois.foltan at oracle.com
Thu Mar 22 16:21:07 UTC 2018


On 3/21/2018 4:25 PM, Lindenmaier, Goetz wrote:

> ... wherever I report the class and it's loader I
> will use class_loader_and_module_name() if I manage
> to usefully extend it's information about the classloaders. ...
Thank you Goetz, I did take a look at the 2 bugs you mentioned below.  
Especially in the case of improving the IAE message, I think reporting 
the module name is a must since lack of readability between 2 modules or 
failure to export a package within a module can affect access.
Lois

>
>> -----Original Message-----
>> From: Lindenmaier, Goetz
>> Sent: Wednesday, March 21, 2018 9:21 PM
>> To: 'Lois Foltan' <lois.foltan at oracle.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: RE: RFR(M): 8199852: Print more information about class loaders in
>> LinkageErrors.
>>
>> Hi Lois,
>>
>> The intention to normalize the output makes completely sense.
>> It starts with using external_name everywhere ��.
>>
>> But you need a method that reports about a classloader that does
>> not belong to a class. There are places where I want to report three
>> class loaders, but only one class name.
>>
>> For example: "classloader A can not load class B because ..."
>>
>> Also, as I understand, the class loader can be in a different module
>> than the loaded class. So you might want to report both. (Well,
>> this could be handled by the enum you describe).
>>
>> I'll read the docu you mention.  I already had a look at the test
>> you mention, but it seemed not to fit for the messages here.
>> If the tests pass, I will post another change for IllegalAccessError
>> that uses the same method. I wanted to hold that back until
>> this one is finished, but maybe it makes sense to look at all the
>> messages at a time.
>>
>> Please also have a look at the wording of the new messages in the
>> bug description.
>> https://bugs.openjdk.java.net/browse/JDK-8199852
>> https://bugs.openjdk.java.net/browse/JDK-8199940
>>
>> Best regards,
>>    Goetz.
>>
>>
>>> -----Original Message-----
>>> From: Lois Foltan [mailto:lois.foltan at oracle.com]
>>> Sent: Wednesday, March 21, 2018 8:27 PM
>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR(M): 8199852: Print more information about class loaders in
>>> LinkageErrors.
>>>
>>> On 3/21/2018 3:06 PM, Lois Foltan wrote:
>>>
>>>> On 3/21/2018 9:03 AM, Lindenmaier, Goetz wrote:
>>>>
>>>>> Hi Lois,
>>>>>
>>>>> Thanks for looking at this!
>>>>>
>>>>> I had a look at Klass::class_loader_and_module_name(), but there are
>>>>> places
>>>>> where you only want to report the class loader information, therefore I
>>>>> decided to do it this way. (If you like this, I have more of these in
>>>>> work :)).
>>>>> For example see expectedErrorMessageDuplicate1 in the test.
>>>>> Also, there might just be a classloader at hand, not a class as needed
>>>>> for that method.
>>>>>
>>>>> But maybe it would make sense to call describe_external() in
>>>>> class_loader_and_module_name() to get more information about
>>>>> the classloader?
>>>> Hi Goetz,
>>>>
>>>> In the JDK 9 time frame we strove to construct the string representing
>>>> the class loader, module name & module version in a defined,
>>>> structured manner.  This allows for consistency across error messages,
>>>> stack dumps, etc.  Use of Klass::class_loader_and_name() gives us this
>>>> consistency and you can see some examples of its use in
>>>> ClassCastException messages. See,
>>>> https://bugs.openjdk.java.net/browse/JDK-8165550 and the test,
>>>> test/hotspot/jtreg/runtime/modules/CCE_module_message.java. I
>>> strongly
>>>> encourage you to use Klass::class_loader_and_name() and not add
>>>> describe_external().  Klass::class_loader_and_name() could be enhanced
>>>> to take an enum parameter that allows for tailoring of the message
>>>> itself, for example including/not including the module name when
>>>> available, including the parent loader, etc.  It could be pulled out
>>>> of Klass for use to obtain a class loader's name when a Klass is not
>>>> available, although Coleen just recently moved it to Klass.  I would
>>>> support this type of change.
>>> See the javadoc for java.lang.StackTraceElement,
>>>
>> https://docs.oracle.com/javase/9/docs/api/java/lang/StackTraceElement.ht
>>> ml.
>>> Specifically the API Note in the StackTraceElement.toString()
>>> description which documents the format and contains examples.
>>> Lois
>>>
>>>> Thanks,
>>>> Lois
>>>>
>>>>> Best regards,
>>>>>     Goetz.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lois Foltan [mailto:lois.foltan at oracle.com]
>>>>>> Sent: Mittwoch, 21. März 2018 13:22
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>>> runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(M): 8199852: Print more information about class
>>>>>> loaders in
>>>>>> LinkageErrors.
>>>>>>
>>>>>> On 3/21/2018 7:55 AM, Lindenmaier, Goetz wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> ClassLoaders have a field containing a name since Java 9.
>>>>>>>
>>>>>>> This change improves some of the messages of LinkageErrors to
>>>>>>> print the name of the loader involved, as well as the parent of the
>>>>>>> loader.
>>>>>>> This simplifies tracking down the component causing an error in large
>>>>>>> Java systems.
>>>>>>>
>>>>>>> Please review:
>>>>>>> http://cr.openjdk.java.net/~goetz/wr18/8199852-
>>>>>> exMsg_Linkage/01/index.html
>>>>>>> I ran this through all our tests (jck, jtreg, spec etc).  I will
>>>>>>> run it through
>>>>>> submit-hs
>>>>>>> (or jdk/submit) once it's reviewed.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>      Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> This looks promising and something that we started to do in the JDK 9
>>>>>> time frame.  Instead of adding the new method
>>>>>> java_lang_ClassLoader::describe_external() can you possible
>>> use/improve
>>>>>> upon Klass::class_loader_and_module_name() in order to avoid
>>> duplicate
>>>>>> code?
>>>>>>
>>>>>> Thanks,
>>>>>> Lois



More information about the hotspot-runtime-dev mailing list