RFR(M): 8199852: Print more information about class loaders in LinkageErrors.
mandy.chung at oracle.com
Thu Mar 29 04:44:53 UTC 2018
On 3/29/18 9:54 AM, David Holmes wrote:
>> I think Lois suggests to consider the well-defined pattern used in
>> printing stack trace when appropriate. It's designed to be compact
>> and provide the adequate information for troubleshooting.
>> Reading JDK-8199940 and JDK-8199852, a relevant format is the
>> exception message in IllegalAccessError (and IllegalAccessException
>> thrown by core reflection) that I have added a comment in
>> class $FROM_CLASS (in $FROM_MODULE) cannot access class $TO_CLASS (in
>> $TO_MODULE) because $TO_MODULE does not export $PACKAGE_OF_TO_CLASS
>> to $FROM_MODULE
>> The format of the module is:
>> if it's a named module, it will print as "module $MODULE"
>> if it's an unnamed module, it will print as "unnamed module
>> @0xnnnnnnnn" where 0xnnnnnnnn is the identity hash code of the module.
>> A module is defined to one class loader.
> That is not relevant here as we are dealing with classloader names,
> not modules.
The loader constraint error message may include a type name where the
module name can be applied.
>> Omitting the builtin class loader has no loss of information for
>> troubleshooting. The boot loader, platform loader and app loader
>> each has one unnamed module. The packages defined to a named module
>> are fixed. It may not look obviously to which class loader/unnamed
>> module the class of the stack frame is defined.
> We're talking about unnamed classloaders not the unnamed modules.
Okay. If the stack frame is for an unnamed classloader and unnamed
module, the class would be defined by a custom class loader and so no
change to the stack trace output.
In this context (error message involving class loaders), unnamed class
loader has been represented by its type. I agree there is no need to
follow the stack trace output format to omit unnamed class loader.
>> I share Lois's concern in including the parent loader in the error
>> The parent loader does not cover all cases. A well-defined class
> The intent is not to imply that you can tell how/if a loader delegates
> simply by listing its parent. The listing of the parent simply serves
> to tell you what the parent is - no more, no less.
In addition, the intent is to help troubleshooting. What I tried is to
say that including the parent can only help certain cases. It seems
that we should look into each LinkageError and determine if the parent
loader is involved in such error (maybe it does. I'm unfamiliar to
these error messages).
It'd be useful to add in JDK-8199852 how the parent loader is involved
in each error message.
More information about the hotspot-runtime-dev