Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #7038

Re: virtual method lookup and accessibility

From kedar mhaswade <kedar.mhaswade@gmail.com>
Newsgroups comp.lang.java.programmer
Subject Re: virtual method lookup and accessibility
Date 2011-08-12 07:20 -0700
Organization http://groups.google.com
Message-ID <46854e03-8e87-4ae1-ba08-ac7a3253b57a@u28g2000prm.googlegroups.com> (permalink)
References <81218f19-7d4f-49b2-a83b-888d2eea284a@a4g2000yqg.googlegroups.com>

Show all headers | View raw


On Aug 12, 2:21 am, Jay Foad <jay.f...@gmail.com> wrote:
> The language spec section 15.12.4.4 "Locate Method to Invoke" (http://
> java.sun.com/docs/books/jls/third_edition/html/
> expressions.html#15.12.4.4) describes how run-time virtual method
> lookup works, and then says:
>
> "The above procedure will always find a non-abstract, accessible
> method to invoke, provided that all classes and interfaces in the
> program have been consistently compiled."
>
> Is this true? Specifically, is the method that's invoked always
> "accessible" from the class containing the method invocation
> expression?
>
> I think this is a counter-example:
>
> package A;
> public class C {
>     protected void f() {
>         System.out.println("Hello from C");
>     }
>
> }
>
> package B;
> public class D extends A.C {
>     protected void f() {
>         System.out.println("Hello from D");
>     }
>
> }
>
> package A;
> public class E {
>     public static void main(String args[]) {
>         C c = new B.D();
>         c.f();
>     }
>
> }
>
> If I compile and run this I get:
>
> $ javac ?/*.java
> $ java A.E
> Hello from D
>
> So A.E has invoked B.D.f(); but B.D.f() is not accessible from A.E,
> because it is protected and in a different package.
>
> Is this a bug in the language spec?
>
> Thanks,
> Jay.

Interesting!
This appears an anomaly, however the two bullet points at
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#250473
seem to cover the curious case where although B.D.f() (, which
"overrides" A.C.f()) is inaccessible to A.E when invoked on an
instance whose compile time type is B.D, the resolution at runtime
finds it when invoked on an instance of A.C.

This could be a spec bug, but compiler seems to behave as the spec
says.

(BTW, the package names should be all lower-case).

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

virtual method lookup and accessibility Jay Foad <jay.foad@gmail.com> - 2011-08-12 02:21 -0700
  Re: virtual method lookup and accessibility kedar mhaswade <kedar.mhaswade@gmail.com> - 2011-08-12 07:20 -0700
  Re: virtual method lookup and accessibility Lew <lewbloch@gmail.com> - 2011-08-12 06:55 -0700
  Re: virtual method lookup and accessibility Jay Foad <jay.foad@gmail.com> - 2011-08-12 08:27 -0700
    Re: virtual method lookup and accessibility Lew <lewbloch@gmail.com> - 2011-08-12 14:46 -0700
  Re: virtual method lookup and accessibility Roedy Green <see_website@mindprod.com.invalid> - 2011-08-12 14:43 -0700

csiph-web