Hi Peter,
Thank you very much for your detailed and very informative explanation. I
have one more question for clarification.
If I have the following code:
abstract class A {
public void foo() {}
}
import java.lang.reflect.*;
public class B extends A {
public static void main(String[] args) throws Exception {
System.out.println("----- getDeclaredMethods -----");
Method[] methods = B.class.getDeclaredMethods();
for( int i = 0 ; i < methods.length ; i++ ){
System.out.println(methods[i]);
}
}
}
If I compile and run this class "java --classpath . B" I get I get the
following output:
----- getDeclaredMethods -----
public static void B.main(java.lang.String[]) throws java.lang.Exception
public void B.foo()
which seems to fit with your explanation (noting that A is an abstract
class). However, if I make A a public class
public class A {
public void foo() {}
}
the output is different and doesnt contain the foo() method.
----- getDeclaredMethods -----
public static void B.main(java.lang.String[]) throws java.lang.Exception
Is this as expected?
Should there be a difference between the output from running the
getDelaredMethods() on
1) a class extending an abstract class with a public method (non abstract)
and
2) a class extending a public class with a public method?
Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groe...@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From: Peter Levart <peter.lev...@gmail.com>
To: Steve Groeger <groe...@uk.ibm.com>, OpenJDK Core Libs Developers
<core-libs-dev@openjdk.java.net>
Date: 02/01/2019 17:45
Subject: Re: Class.getDeclaredMethods() is returning inherited
methods
Hi Steve,
What you have observed is an artifact of how Java the language is
compiled into bytecode contained in .class files and the fact that Java
reflection API returns information about the compiled .class files. The
quoted sample code:
package x.y;
class A {
public void m() {
}
}
public class B {
}
...is one example where the compiler must create a synthetic method in
class B which overrides public method in class A and delegates to it.
Java access checks allow invoking A.m() only from package x.y since A is
a package private class. OTOH m() is a public method and as such is
inherited by B. so m() can be called on an instance of type B from
anywhere because B is a public class. To accommodate that, javac
synthesizes public method B.m() which delegates to A.m() as thought you
would have written the following code:
package x.y;
class A {
public void m() {
}
}
public class B {
public void m() {
super.m();
}
}
... B.class.getDeclaredMethods() therefore returns this synthetic method
B.m() and not the inherited method A.m(). You can verify that by
invoking .getDeclaringClass() on it, which should give you B.class and
not A.class.
Strictly speaking such synthetic method on B is not really needed by JVM
to invoke A.m() from anywhere via the instance of B. Invocation of m()
given an instance of B could be compiled by javac in exactly the same
way even if there was no synthetic method B.m(). Javac could pretend
there is a method B.m() and emit invoke instruction referencing the
imaginative method. At runtime JVM would dispatch the virtual call to
inherited A.m and allow such call from anywhere since it references a
public method in a public class (although imaginative).
The only reason javac generates synthetic method B.m() is to actually
allow A.m() to be called via reflection API. Reflection API does not
allow invoking A.m() directly from anywhere, but it allows invoking the
synthetic B.m() which then delegates to A.m().
If we wanted to get rid of this synthetic method, reflection would have
to be fixed 1st to accommodate calling public methods inherited from
non-public classes if they are called via an instance of a public
subclass (or a subclass of it). The reason this has not been done yet is
probably that it is more tricky that it seems at first. Imagine the
following situation:
package p1;
class A {
public void m() {
}
}
public class B extends A {
}
package p2;
class C extends B {
}
public class Builder {
public static B build() {
return new C();
}
}
package p3;
public class App {
public static void main(String[] args) {
B b = p2.Builder.build();
b.m(); // << HERE
}
}
...javac would have an easy job here. It knows the static (compile-time)
type of variable b (which is a public class B) so it can directly emit
invoke instruction for imaginative method B.m() here.
Reflection API OTOH has a more difficult job in the following code:
package p3;
public class App {
public static void main(String[] args) {
B b = p2.Builder.build();
Method m = B.class.getMethod("m"); // m.getDeclatingClass() ==
A.class
m.invoke(b); // << HERE
}
}
...reflection has at its disposal:
- a Method object 'm' representing method A.m() which is located in a
non-public class p1.A
- a target instance 'b' which is of type p2.C which is also a non-public
class
- the invocation is being performed from package p3
In order for reflection to allow such invocation it would have to assume
that such invocation is performed via some imaginative method X.m() such
that:
- X is a public class and is a subclass of A
- C is a subclass of X
Such decision is inherently non-local meaning that reflection would have
to search class hierarchy to allow it. It is possible though, but
probably to complicated for such use case.
What do others think?
Regards, Peter
On 1/2/19 5:33 PM, Steve Groeger wrote:
> I am looking into an issue where the Class.getDeclaredMethods() is
> returning inherited methods,
> where the Java Doc here:-
>
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods()
> states:-
>
> "Returns an array containing Method objects reflecting all the declared
> methods of the class or interface represented by this Class object,
> including public, protected, default (package) access, and private
> methods, but excluding inherited methods".
>
> with the last part of the statement being the relevant part, "but
> excluding inherited methods"
>
> This was raised as an issue a long time ago:
>
https://bugs.openjdk.java.net/browse/JDK-6815786
but has not been fixed
> and is still an issue in JDK11.
>
> Before I go looking into why this is occurring and producing a fix, is
> this still seen as an issue and does it need to be fixed / should it be
> fixed.
> I dont want to do lots of investigation and produce a fix just to be
told
> we cant contribute this as it will break too many people that might have
> been using this feature !!!!
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groe...@uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
