Hi Peter,
Thanks again for your explanation.
It was the public vs. non-public part that I had missed and I was getting
confused thinking it was related to abstract vs. non-abstract classes.
The generation of the synthetic methods and why the methods are shown via
the getDeclaredMethods() makes a lot more sense now.
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>
Cc: OpenJDK Core Libs Developers <core-libs-dev@openjdk.java.net>
Date: 03/01/2019 11:33
Subject: Re: Class.getDeclaredMethods() is returning inherited
methods
Hi Steve,
The difference you observe between variants of class A is not about the
"abstract" vs. non-"abstract" but about "public" vs. non-"public"...
Your variants of class A are:
public class A {
public void foo() {}
}
vs.
abstract class A {
public void foo() {}
}
The 1st is public but the 2nd is package-private. Try with the following
variant:
class A {
public void foo() {}
}
... and you'll see the same behavior as with abstract package-private
class. Try also with the following variant:
public abstract class A {
public void foo() {}
}
...and you'll see the same behavior as with public concrete class.
The reason why javac does not generate synthetic method when extending
public class is obvious. It is not needed since A.m() can be invoked
from anywhere if A is public.
Regards, Peter
On 1/3/19 10:33 AM, Steve Groeger wrote:
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
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
