-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b109
-
generic
-
generic
-
Verified
The following program, when compiled on JDK9 dev tip:
interface Foo<X> {
void g(X x);
}
class Test2 {
void m() {
Foo<String> fs = new Foo<>() {
public void g(String s) { }
void someMethod() { }
};
}
}
elicits the error:
/home/srikanth/tmp/X.java:9: error: method does not override or implement a method from a supertype
void someMethod() { }
^
1 error
This is intentional.
There are some cases with diamond inference where the inferred types are
not what would be "obvious" choices from the p.o.v of a non-discerning user. So a programmer may end up writing some methods that
seemingly override a super type method but don't in reality. To help
diagnose the situation, the spec requires that all non-private instance
methods of a <> inferred anonymous class be treated as though they were
annotated with @Override (See https://bugs.openjdk.java.net/browse/JDK-8073593)
However, the message emitted as of now does not make this explicit and so is a potential grounds for confusion (and invalid defect reports)
javac should emit a clearer message.
interface Foo<X> {
void g(X x);
}
class Test2 {
void m() {
Foo<String> fs = new Foo<>() {
public void g(String s) { }
void someMethod() { }
};
}
}
elicits the error:
/home/srikanth/tmp/X.java:9: error: method does not override or implement a method from a supertype
void someMethod() { }
^
1 error
This is intentional.
There are some cases with diamond inference where the inferred types are
not what would be "obvious" choices from the p.o.v of a non-discerning user. So a programmer may end up writing some methods that
seemingly override a super type method but don't in reality. To help
diagnose the situation, the spec requires that all non-private instance
methods of a <> inferred anonymous class be treated as though they were
annotated with @Override (See https://bugs.openjdk.java.net/browse/JDK-8073593)
However, the message emitted as of now does not make this explicit and so is a potential grounds for confusion (and invalid defect reports)
javac should emit a clearer message.
javac should emit a clearer diagnostic when a <> inferred anonymous type's non-private methods don't override super's
-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b109
-
generic
-
generic
-
Verified
The following program, when compiled on JDK9 dev tip:
interface Foo<X> {
void g(X x);
}
class Test2 {
void m() {
Foo<String> fs = new Foo<>() {
public void g(String s) { }
void someMethod() { }
};
}
}
elicits the error:
/home/srikanth/tmp/X.java:9: error: method does not override or implement a method from a supertype
void someMethod() { }
^
1 error
This is intentional.
There are some cases with diamond inference where the inferred types are
not what would be "obvious" choices from the p.o.v of a non-discerning user. So a programmer may end up writing some methods that
seemingly override a super type method but don't in reality. To help
diagnose the situation, the spec requires that all non-private instance
methods of a <> inferred anonymous class be treated as though they were
annotated with @Override (See https://bugs.openjdk.java.net/browse/JDK-8073593)
However, the message emitted as of now does not make this explicit and so is a potential grounds for confusion (and invalid defect reports)
javac should emit a clearer message.
interface Foo<X> {
void g(X x);
}
class Test2 {
void m() {
Foo<String> fs = new Foo<>() {
public void g(String s) { }
void someMethod() { }
};
}
}
elicits the error:
/home/srikanth/tmp/X.java:9: error: method does not override or implement a method from a supertype
void someMethod() { }
^
1 error
This is intentional.
There are some cases with diamond inference where the inferred types are
not what would be "obvious" choices from the p.o.v of a non-discerning user. So a programmer may end up writing some methods that
seemingly override a super type method but don't in reality. To help
diagnose the situation, the spec requires that all non-private instance
methods of a <> inferred anonymous class be treated as though they were
annotated with @Override (See https://bugs.openjdk.java.net/browse/JDK-8073593)
However, the message emitted as of now does not make this explicit and so is a potential grounds for confusion (and invalid defect reports)
javac should emit a clearer message.