Implied readability: calling toString()

Sander Mak sander.mak at luminis.eu
Mon May 30 07:39:57 UTC 2016


Thanks Jochen, makes total sense that you'd need readability since the Text type could of course override toString(). I think I led myself astray because the output of javap for this invocation was

      25: invokevirtual #8                  // Method java/lang/Object.toString:()Ljava/lang/String;


Sander

> On 27 May 2016, at 14:18, Jochen Theodorou <blackdrag at gmx.org> wrote:
> 
> On 27.05.2016 13:39, Sander Mak wrote:
>> I'm running into the following compilation error (build 9-ea+116-2016-04-28-175027.javare.4913.nc):
>> 
>> $ javac -modulesourcepath src -d out $(find . -name '*.java')
>> .src/test/client/Client.java:13: error: toString() in Object is defined in an inaccessible class or interface
>>       repository.findText(id).toString();
>> 
>> Besides the fact that the error message is somewhat confusing (how would toString() in Object ever be inaccessible?), this example raises a question on implied readability for me.
>> 
>> In this case, repository.findText() returns a type Text that normally requires implied readability. I deliberately omitted the 'public' from the corresponding requires clause, since I thought that calling toString() (or equals/hashCode) would be possible without having readability on the actual type. In the end it's just an invokevirtual on j.l.Object, right? Am I missing something here? It works fine when adding back the 'public' to the requires clause, obviously.
> 
> It is an invokevirtual on Object only if the signature of findText(id) returns Object. If the method is declared to return Server then it is an invokevirtual on Server instead and requires the class Server to be accessible
> 
> bye Jochen
> 



More information about the jigsaw-dev mailing list