Method reference to private interface method - java

Consider the following code:
public class A {
public static void main(String[] args) {
Runnable test1 = ((I)(new I() {}))::test; // compiles OK
Runnable test2 = ((new I() {}))::test; // won't compile
}
interface I {
private void test() {}
}
}
I don't really get the point... I understand that test() method is private. But what is changed if we cast an anonymous class to its interface ((I)(new I() {}))? More precisely I would like to see a particular JLS point which allows that trick.
P.S. I have reported it as a bug of compiler (ID : 9052217). It seems to me that Runnable test2 = ((new I() {}))::test; should be compiled fine in this particular case.
P.P.S. So far there was created a bug based on my report: https://bugs.openjdk.java.net/browse/JDK-8194998 . It might be that it will be closed as "won't fix" or whatsever.

This is not a new issue, and has nothing to do with private interface methods or method references.
If you change code to extend a class instead of implement an interface, and to call the method instead of referencing it, you still get exact same problem.
class A {
public static void main(String[] args) {
((I)(new I() {})).test(); // compiles OK
((new I() {})).test(); // won't compile
}
class I {
private void test() {}
}
}
However, that code can be applied to older Java versions, and I tried Java 9, 8, 7, 6, 5, and 1.4. All behave the same!!
The issue is that private methods are not inherited1, so the anonymous class doesn't have the method, at all. Since the private method doesn't even exist in the anonymous class, it cannot be called.
When you cast to I, the method now exists for the compiler to see, and since I is an inner class, you are granted access (through a synthetic method), even though it is private.
In my opinion, it is not a bug. It's how private methods work in context of inheritance.
1) As found by Jorn Vernee in JLS 6.6-5: "[A private class member] is not inherited by subclasses".

private methods are not inherited (Closest I found so far is: JLS6.6-5: "[A private class member] is not inherited by subclasses"). That means that you can not access a private method, from a subtype (because it simply does not 'have' that method). For instance:
public static void main(String[] args) {
I1 i1 = null;
I2 i2 = null;
i1.test(); // works
i2.test(); // method test is undefined
}
interface I1 {
private void test() {}
}
interface I2 extends I1 {}
That also means that you can not directly access the test method through the type of an anonymous subclass.
The type of the expression:
(new I() {})
Is not I, but actually the non-denotable type of the anonymous subclass, so you can't access test through it.
However, the type of the expression:
((I) (new I() {}))
is I (as you explicitly cast it to I), so you can access the test method through it. (just like you can do ((I1) i2).test(); in my above example)
Similar rules apply to static methods, as they are also not inherited.

Invoking a private method is only possible through an expression of exactly the declaring type, regardless of the scenario.
Let’s explain it with the simplest example
public class A {
public static void main(String[] args) {
B b = new B();
b.someMethod(); // does not compile
A a = b;
a.someMethod(); // no problem
}
private void someMethod() {}
}
class B extends A {
}
You might expect this to compile using b.someMethod() to invoke A’s someMethod(). But what if B was declared as
class B extends A {
public void someMethod() {}
}
This is possible, as the private void someMethod() is not inherited, so public void someMethod() does not override it. But it should be clear that now b.someMethod() should invoke B’s method.
So if it was allowed that b.someMethod() ends up at a private method of A, it would depend on whether B declares another someMethod(), at which actual method the call will end up. And that obviously contradicts the entire concept of private methods. private methods are not inherited and never overridden, so it should not depend on the subclass, whether a call ends up at a private method or a subclass’ method.
Your example is similar. The anonymous inner class that implements I could declare its own test() method, e.g. Runnable test2 = ((new I() {void test() {}}))::test; so it would depend on that anonymous inner class, whether the private method of I or a method of that anonymous inner class gets invoked, which would be unacceptable. Of course, with such an inner class, directly preceding the invocation or method reference, a reader can immediately tell, at which method the invocation will end up, but it would be very inconsistent, if this was allowed for an anonymous inner class but nothing else.
The private method of I is accessible to A as it is a the nested interface, but as shown with the simpler example above, the rule is not about accessibility, as the rule even applies when the private method is within the same class as the caller.

This is counter-intuitive. First let's simplify this a bit:
static interface Inter {
private void test() {
System.out.println("test");
}
}
public static void main(String[] args) {
((Inter) new Inter() {
}).hashCode();
}
This makes sense as you are calling the public hashCode method, here is the (important part only) byte code for it:
public static void main(java.lang.String[]);
Code:
0: new #2 // class com/test/DeleteMe$1
3: dup
4: invokespecial #3 // Method com/test/DeleteMe$1."<init>":()V
7: invokevirtual #4 // Method java/lang/Object.hashCode:()I
10: pop
11: return
Looks very sane to me. Now let's change that to calling test():
public static void main(String[] args) {
((Inter) new Inter() {
}).test();
}
The byte code for this:
invokestatic #4 // InterfaceMethod com/test/DeleteMe$Inter.access$000:(Lcom/test/DeleteMe$Inter;)V
Since private methods are not inherited, you are actually "going" to that method via the access$n static synthetic method.

Related

Surprising access to fields with Java anonymous class

I'm trying to better understand the concept of anonymous classes in Java. From other answers on this website, I learned that an anonymous class can access non-final fields of the enclosing class using OuterClass.this.myField.
I made the following simple test case with an interface, AnonInt, and a class AnonTest with a method foo which returns an instance of an anonymous class implementing AnonInt. Dspite the fact that I'm using System.out.println(a) rather than System.out.println(AnonTest.this.a) the code works and prints the correct result. How can this be?
public interface AnonInt {
void print();
}
public class AnonTest {
private int a;
public AnonTest(int a) {
this.a = a;
}
public AnonInt foo() {
return new AnonInt() {
public void print() {
System.out.println(a);
}
};
}
public static void main(String[] args) {
AnonTest at = new AnonTest(37);
AnonInt ai = at.foo();
ai.print();
}
}
Despite the fact that I'm using System.out.println(a) rather than System.out.println(AnonTest.this.a) the code works and prints the correct result. How can this be?
Since the reference to a is unambiguous in your context, the two expressions reference the same field.
Generally, AnonTest.this is required in a very specific context - when your method needs to access AnonTest object itself, rather than accessing one of its members. In case of your program, this is unnecessary: the compiler resolves the expression a to the object AnonTest.this.a, and passes it to System.out.println.

Why the call to the parent constructor is not the first call in the compiler generated constructor for Inner class?

Consider the following Test class to demonstrate the inner class behavior in Java. The main code is in the run method. Rest is just plumbing code.
public class Test {
private static Test instance = null;
private Test() {
}
private void run() {
new Sub().foo();
}
public static void main(String[] args) {
instance = new Test();
instance.run();
}
class Super {
protected void foo() {
System.out.println("Test$Super.Foo");
}
}
class Sub extends Super {
public void foo() {
System.out.println("Test$Sub.Foo");
super.foo();
}
}
}
I am just printing below the javap output for the hidden Sub constructor:
so.Test$Sub(so.Test);
Code:
0: aload_0
1: aload_1
2: putfield #1 // Field this$0:Lso/Test;
5: aload_0
6: aload_1
7: invokespecial #2 // Method so/Test$Super."<init>":(Lso/Test;)V
10: return
Normally the compiler ensures that the sub-class constructor would call into the super-class constructor first before going on to initialize its own fields. This aids in a correctly constructed object but I am seeing an aberration from the normative behavior in the case of the constructor that the compiler generates for an Inner class. Why so? Is it specified by JLS?
P.S: I know that the inner class contains a hidden reference to the outer class and that reference is being set here in the above javap output. But the question is why it is set before calling super constructor. What am I missing?
An inner class is an abstraction that should be as transparent to a Java programmer as possible. Consider the following class structure and think about what would happen if you set the $this field only after calling the inner class's super constructor.
class Foo {
Foo() { System.out.println(foo()); }
String foo() { return "foo"; }
}
class Bar {
String bar() { return "bar"; }
class Qux extends Foo {
#Override
String foo() { return bar(); }
}
}
Note how the overridden method in class Qux calls a method of its outer class Bar. For this to work, the $this field that holds the Bar instance must be set before the super constructor of Foo is invoked. Otherwise, you would end up with a NullPointerException as the field is not yet initialized. To make this more clear, look at the following call chain of any instanciation of a Qux instance:
Qux() -> Foo() -> this.foo() -> $this.bar()
As a programmer that is not to familiar with the implementation of an inner class, you would wonder where this exception comes from. In order to make the inner class abstraction transparent, you must set the field first, otherwise you would be stuck with a quite leaky abstraction. I do not argue that this makes the above example a good implementation, but it is legal.

Why doesn't the compiler complain when I try to override a static method?

I know that we cannot override static methods in Java, but can someone explain the following code?
class A {
public static void a() {
System.out.println("A.a()");
}
}
class B extends A {
public static void a() {
System.out.println("B.a()");
}
}
How was I able to override method a() in class B?
You didn't override anything here. To see for yourself, Try putting #Override annotation before public static void a() in class B and Java will throw an error.
You just defined a function in class B called a(), which is distinct (no relation whatsoever) from the function a() in class A.
But Because B.a() has the same name as a function in the parent class, it hides A.a() [As pointed by Eng. Fouad]. At runtime, the compiler uses the actual class of the declared reference to determine which method to run. For example,
B b = new B();
b.a() //prints B.a()
A a = (A)b;
a.a() //print A.a(). Uses the declared reference's class to find the method.
You cannot override static methods in Java. Remember static methods and fields are associated with the class, not with the objects. (Although, in some languages like Smalltalk, this is possible).
I found some good answers here: Why doesn't Java allow overriding of static methods?
That's called hiding a method, as stated in the Java tutorial Overriding and Hiding Methods:
If a subclass defines a class method with the same signature as a
class method in the superclass, the method in the subclass hides the
one in the superclass.
static methods are not inherited so its B's separate copy of method
static are related to class not the state of Object
You didn't override the method a(), because static methods are not inherited. If you had put #Override, you would have seen an error.
A.java:10: error: method does not override or implement a method from a supertype
#Override
^
1 error
But that doesn't stop you from defining static methods with the same signature in both classes.
Also, the choice of method to call depends on the declared type of the variable.
B b = null;
b.a(); // (1) prints B.a()
A a = new B();
a.a(); // (2) prints a.a()
At (1), if the system cared about the identity of b, it would throw a NPE. and at (2), the value of a is ignored. Since a is declared as an A, A.a() is called.
Your method is not overridden method. you just try to put #Override annotation before your method in derived class. it will give you a compile time error. so java will not allow you to override static method.
While goblinjuice answer was accepted, I thought the example code could improved:
public class StaticTest {
public static void main(String[] args) {
A.print();
B.print();
System.out.println("-");
A a = new A();
B b = new B();
a.print();
b.print();
System.out.println("-");
A c = b;
c.print();
}
}
class A {
public static void print() {
System.out.println("A");
}
}
class B extends A {
public static void print() {
System.out.println("B");
}
}
Produces:
A
B
-
A
B
-
A
If B had overridden print() it would have write B on the final line.
Static methods will called by its Class name so we don't need to create class object we just cal it with class name so we can't override static
for example
class AClass{
public static void test(){
}
}
class BClass extends AClass{
public static void test(){}
}
class CClass extends BClass{
public static void main(String args[]){
AClass aclass=new AClass();
aclass.test(); // its wrong because static method is called
// by its class name it can't accept object
}
}
we just call it
AClass.test();
means static class can't be overridden
if it's overridden then how to cal it .
Static members belong to class not to any objects. Therefore static methods cannot be overriden. Also overiding happens at run time therefore compiler will not complain.
Howeve, you can add #Override annotation to method. This will flag compiler error.

Static method override

class XYZ{
public static void show(){
System.out.println("inside XYZ");
}
}
public class StaticTest extends XYZ {
public static void show() {
System.out.println("inside statictest");
}
public static void main(String args[]){
StaticTest st =new StaticTest();
StaticTest.show();
}
}
though we know static methods cant be overridden. Then what actually is happening?
Static methods belong to the class. They can't be overridden. However, if a method of the same signature as a parent class static method is defined in a child class, it hides the parent class method. StaticTest.show() is hiding the XYZ.show() method and so StaticTest.show() is the method that gets executed in the main method in the code.
Its not overriding they are two different method in two different class with same signature. but method from XYZ isn't available in child class through inheritance .
It will call method from StaticTest
It's not overriden properly said... Static methods are 'tied' to the class so
StaticTest.show();
and
XYZ.show();
are two totally different things. Note you can't invoke super.show()
To see the difference you have to use more powerful example:
class Super {
public static void hidden(Super superObject) {
System.out.println("Super-hidden");
superObject.overriden();
}
public void overriden() {
System.out.println("Super-overriden");
}
}
class Sub extends Super {
public static void hidden(Super superObject) {
System.out.println("Sub-hidden");
superObject.overriden();
}
public void overriden() {
System.out.println("Sub-overriden");
}
}
public class Test {
public static void main(String[] args) {
Super superObject = new Sub();
superObject.hidden(superObject);
}
}
As Samit G. already have written static methods with same signature in both base and derived classes hide the implementation and this is no-overriding. You can play a bit with the example by changing the one or the another of the static methods to non-static or changing them both to non-static to see what are the compile-errors which the java compiler rises.
It's not an override, but a separate method that hides the method in XYZ.
So as I know, any static member (method or state) is an attribute of a class, and would not be associated with any instance of a class. So in your example, XYZ is a class, and so is StaticTest (as you know). So by calling the constructor two things first happen. An Object of type Class is created. It has a member on it call showed(). Class, XYZ.class, extends from Object so has all those Object methods on it plus show(). Same with the StaticClass, the class object has show() on it as well. They both extend java.lang.Object though. An instance of StaticClass would also be an instance of XYZ. However now the more interesting question would be what happens when you call show() on st?
StaticClass st = new StaticClass();
st.show();
XYZ xyz = st;
xyz.show();
What happens there? My guess is that it is StaticClass.show() the first time and XYZ.show() the second.
Static methods are tied to classes and not instances (objects).
Hence the invocations are always ClassName.staticMethod();
When such a case of same static method in a subclass appears, its called as refining (redefining) the static method and not overriding.
// Java allows a static method to be called from an Instance/Object reference
// which is not the case in other pure OOP languages like C# Dot net.
// which causes this confusion.
// Technically, A static method is always tied to a Class and not instance.
// In other words, the binding is at compile-time for static functions. - Early Binding
//
// eg.
class BaseClass
{
public static void f1()
{
System.out.println("BaseClass::f1()...");
} // End of f1().
}
public class SubClass extends BaseClass
{
public static void f1()
{
System.out.println("SubClass::f1()...");
// super.f1(); // non-static variable super cannot be referenced from a static context
} // End of f1().
public static void main(String[] args)
{
f1();
SubClass obj1 = new SubClass();
obj1.f1();
BaseClass b1 = obj1;
b1.f1();
} // End of main().
} // End of class.
// Output:
// SubClass::f1()...
// SubClass::f1()...
// BaseClass::f1()...
//
//
// So even though in this case, called with an instance b1 which is actually referring to
// an object of type SuperClass, it calls the BaseClass:f1 method.
//

Constructor's Private scope

Given this code snippet, could you explain why it woks?
The thing is that the class constructor is marked private, so should not it prevent us to call it with new operator?
public class Alpha {
protected Alpha() {}
}
class SubAlpha extends Alpha {
private SubAlpha() {System.out.println("ok");}
public static void main(String args[]) {
new SubAlpha();
}
}
It all works because the static method is part of the class and it can see all private fields and methods, right? Outside this "new" initialization would never work?
The only private constructor in your question is SubAlpha, which SubAlpha itself is calling. There's no issue, a class can call its own private methods. The Alpha constructor is protected, so SubAlpha has access to it.
Edit: Re your edit: Yes, exactly. A separate class (whether a subclass or not) would not have access to SubAlpha's private constructor and could not successfully construct a new SubAlpha().
Example 1:
public class Beta
{
public static final void main(String[] args)
{
new SubAlpha();
// ^--- Fails with a "SubAlpha() has private access in SubAlpha"
// compilation error
}
}
Example 2:
public class SubSubAlpha extends SubAlpha
{
private subsubAlpha()
{
// ^== Fails with a "SubAlpha() has private access in SubAlpha"
// compilation error because of the implicit call to super()
}
}
This is, of course, constructor-specific, since scope is always member-specific. If a class has a different constructor with a different signature and a less restrictive scope, then a class using it (including a subclass) can use that other constructor signature. (In the case of a subclass, that would require an explicit call to super(args);.)
The code works as the main method is also in the same class. You may not be able to initialize SubAplha from a different class.

Categories

Resources