[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-jigsaw-dev
Subject: Re: Question on returning instances of a (not exported) derived class
From: Peter Levart <peter.levart () gmail ! com>
Date: 2016-08-26 9:21:47
Message-ID: 36d7315d-40bd-b647-da1f-a971eecc6ddc () gmail ! com
[Download RAW message or body]
Hi Martin,
On 08/25/2016 02:03 PM, Martin Lehmann wrote:
>
> I am a bit confused here, as you mention toString() . But in case [3]
> getName() is not related to toString() – at least not that I can see.
>
> InternalData.getName() overwrites Data.getName() , both returning a
> hard-coded String as result value.
>
> So did you mean getName() instead of toString() ? I.e. did you mean:
>
> Ø...because the compiler notices the static type of the
> ***.getName()*** target is InternalData which declares the
> ***getName()*** method (and overrides ***Data::getName*** method). So
> InternalData should be accessible at runtime for this invocation to
> succeed and at compile time for compilation to succeed.
>
> If you did not mean this, I would be lost here... ;-)
>
Yes, you're right. I did mean to type "getName", but my fingers typed
"toString".
The compiler references the most specific type that declares a
particular virtual method in the emited invokedynamic instructrion. In
this case, it is InternalData which is not exported to the module
performing the invocation. Hence the compile-time error.
The compiler could choose to reference the most generic type that
declares a virtual method with no effect on the final runtime behavior
(in this case, it would be Data), but I think the strategy to reference
the most specific type is meant to facilitate a binary-compatible
change: in your case, removing getName() method from Data and separate
compiling it is a binary compatible change. If the compiler choose the
most generic method's declaring class, it would not be, I think.
Regards, Peter
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic