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

[Lindenmaier, Goetz]

Hi Lois, 

I changed  the code as agreed:
http://cr.openjdk.java.net/~goetz/wr18/8199940-exMsg-IllegalAccess/02/

I'm not really sure this is good:

 interface IAE1_A {
     public IAE1_D gen();
 }
 class IAE1_B implements IAE1_A {
     public IAE1_D gen() {
         return null;
     }
 }
A is loaded by "app", B by the custom loader.

The message is now:
"class test.IAE1_B cannot access its superinterface test.IAE1_A"
if there are no names in the loaders.

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.

Or do I misunderstand the test?

Best regards,
  Goetz.



> -----Original Message-----
> From: Lois Foltan <lois.foltan at oracle.com>
> Sent: Thursday, May 24, 2018 10:12 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(M): 8199940: Print more information about class loaders in
> IllegalAccessErrors.
> 
> On 5/16/2018 9:30 AM, Lindenmaier, Goetz wrote:
> 
> > Hi,
> >
> > I finally prepared the webrev for this change.
> > I simplified the messages wrt. to my first intent that was found too
> > verbose.
> >
> > The IllegalAccessErrors in classFileParser report more verbose
> > information about the class loaders.
> > As I understand, the class loaders are the reason for the error here,
> > so I think information about them is useful. See also the tests 1-3.
> > I added reporting whether the class is abstract.
> >
> > In linkResolver, I just switch to class_loader_and_module_name()
> > to report a more verbose class name as Lois requested.
> > I removed mentioning the resolved class in the method case.
> > I report the modifiers of methods/fields.
> > But as I understand, even here the class loader can be the reason
> > of the Error, see tests 6-8.
> >
> > Please review.  I'm happy to improve the messages further :)
> > http://cr.openjdk.java.net/~goetz/wr18/8199940-exMsg-IllegalAccess/01/
> >
> > Best regards,
> >    Goetz.
> Hi Goetz,
> 
> Thanks for making this change, improving IAEs to include class loader
> names has been on our radar as well.  Here are my review comments to
> hopefully move this change forward.
> 
> - src/hotspot/share/classfile/classFileParser.cpp
> Based on further discussion in
> https://bugs.openjdk.java.net/browse/JDK-8199940, I believe you
> suggested changing the calls from describe_external() to loader_name().
> I would support that change or even a change to use
> class_loader_and_module_name().
> 
> - src/hotspot/share/interpreter/linkResolver.cpp
> I think all the changes in this file look great!  I did write a new test
> to demonstrate how an IAE looks when a type with correct module
> readability and package exportability tries to access a private method
> within another type. The IAE generated will contain the following:
> 
> java.lang.IllegalAccessError: tried to access private method
> MySameClassLoader/m2x/p2.c2.method2()V from class
> MySameClassLoader/m1x/p1.c1
> 
> Once your change is in, I will follow up with an RFE to include this
> test with the other accessibility tests in
> open/test/hotspot/jtreg/runtime/modules/AccessCheck.
> 
> Thanks,
> Lois
> 
> 
> 
> 
>