strange choice of method

[Jan Lahoda]

Hello,


This is what I think happens:

- for M1, the `a(String)`, `c()` and `c(String)` are not members of the 
class, while `a()` is (as per JLS 8.2, private members are not inherited)

- for M1, when seeing `a(null)`, the determined type to search (JLS 
15.12.1) is M1, as there's a method called `a` in this class (note that 
arity does not play a role in this step). Hence `a()` is the only candidate.

- for M1, when seeing `c(null)`, there's no `c(...)` in `M1`, so the 
search goes to the enclosing/outer scope (i.e. the determined type to 
search is X), where it finds `c()` and `c(String)`, where the second one 
is resolved.

- for M2, neither `a(..)`, nor `c(...)` are in M2, so the search goes to 
the enclosing/outer scope in both cases, and the resolution finds 
`a(String)` and `c(String)` respectively, from the enclosing scope.


Do I miss something?


Jan


On 09. 06. 25 0:22, Stephan Herrmann wrote:
> In the following code javac raises exactly one error:
>
> //--------------
> public class X {
>         void a() {}
>         private static void a(String s) {}
>         private void c() {}
>         private static void c(String s) {}
>         static class M1 extends X {
>                 public void x() {
>                         a(null);
>                         c(null);
>                 }
>         }
>         static class M2 {
>                 public void x() {
>                         a(null);
>                         c(null);
>                 }
>         }
> }
> //----------------
>
> The first call "a(null)" is rejected, because the no-arg instance 
> method is selected, whereas the second such call is accepted, 
> targeting the static method.
>
> Also both calls "c(null)" are accepted.
>
> Is there any intention behind this?
>
> thanks,
> Stephan
>
> PS: These observations hold for version 5 through 25 ea. javac 1.4 
> actually accepts the program. Not sure if it helps understanding the 
> why of it.