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

[Lindenmaier, Goetz]

Hi,

Let's keep it as is, I'll check on JDK-8169559 and propose 
to simplify it then ... but I assume Lois will implement something
like that anyways.

Is that ok?

(`($C1 and $C2 are in loader $L)`
   I don't think we should mention both classes again.)

Best regards,
  Goetz.


> -----Original Message-----
> From: mandy chung <mandy.chung at oracle.com>
> Sent: Tuesday, June 19, 2018 10:18 PM
> 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,
> 
> I expect that the exception message wording will take several iterations
> to converge on what to omit under what conditions. JDK-8169559 can
> follow up on further simplification.
> 
> When both classes come from the same module (hence same loader), I
> agree
> with you that it'd be helpful not to repeat the same module/loader info
> twice and message like this ($C1 and $C2 are in loader $L) sounds good.
> 
> As for the builtin loaders, we ultimately want to include the module
> info.  For application loader, the common case would be unnamed module.
> Since this is an interim improvement to include custom loader info, it's
> okay with me if you want to leave the builtin loader case to JDK-8169559.
> 
> Lois - are you okay for this issue to reduce to just custom loader case
> like this:
> 
> if one of the loaders is not builtin loader then
>     if (C1's module == C2's module) then
>        append `($C1 and $C2 are in loader $L)`
>     else
>        append `($C1 is in loader $L1; $C2 is in loader $L2)`
> 
> Mandy
> 
> On 6/19/18 9:54 AM, Lindenmaier, Goetz wrote:
> > Hi Mandy,
> >
> >>>       If loader1 is well known
> >>>           print nothing
> >> What is a well known loader?  Are you referring to the built-in loaders?
> > Yes, I would propose to check cld->is_system_class_loader_data() || cld-
> >is_platform_class_loader_data()
> > as in other places.
> >
> > Best regards,
> >    Goetz
> >
> >
> >
> >> -----Original Message-----
> >> From: mandy chung <mandy.chung at oracle.com>
> >> Sent: Tuesday, June 19, 2018 5:03 PM
> >> 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.
> >>
> >>
> >>
> >> 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
> >>>>