Bug 503074 - [1.8][compiler] Eclipse does not issue an error when inheriting an interface with override-equivalent signature
Summary: [1.8][compiler] Eclipse does not issue an error when inheriting an interface ...
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.6   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Sasikanth Bharadwaj CLA
QA Contact: Srikanth Sankaran CLA
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-03 10:50 EDT by Tagir Valeev CLA
Modified: 2023-06-01 06:24 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tagir Valeev CLA 2016-10-03 10:50:17 EDT
Consider the following code:

public interface Parent<T> {
	default void foo(String x) {System.out.println(x);}
	void foo(T x);
	
	@FunctionalInterface
	interface StringChild extends Parent<String> {};
}

Eclipse Neon.1 Release (4.6.1) (org.eclipse.jdt.core_3.12.1.v20160829-0950.jar) does not issue any error or warning on this interface. However javac refuses to compile it with the following message:

Parent.java:8: error: interface StringChild inherits abstract and default for foo(String) from types Parent and Parent
        interface StringChild extends Parent<String> {};
        ^
Parent.java:7: error: Unexpected @FunctionalInterface annotation
        @FunctionalInterface
        ^
  StringChild is not a functional interface
    no abstract method found in interface StringChild
2 errors

I think, this case is covered by JLS 9.4.1.3:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4.1.3

> If an interface I inherits a default method whose signature is override-equivalent with another method inherited by I, then a compile-time error occurs. (This is the case whether the other method is abstract or default.) 

I think, Eclipse should report an error here as well.
Comment 1 Jay Arthanareeswaran CLA 2016-10-04 00:34:03 EDT
I see this on the latest I build too.

Stephan/Sasi, can you confirm if this is indeed a bug on our side?

BTW, if I move the abstract foo method to another interface in the hierarchy, then both compilers accept that.
Comment 2 Sasikanth Bharadwaj CLA 2016-10-04 02:53:47 EDT
(In reply to comment #1)
> I see this on the latest I build too.
> 
> Stephan/Sasi, can you confirm if this is indeed a bug on our side?
> 
> BTW, if I move the abstract foo method to another interface in the hierarchy,
> then both compilers accept that.
I remember seeing a duplicate sometime ago, that we do not report name clash between default and abstract methods in some cases. Will dig it out, but to answer your question, we do have a bug in this area and I believe it is not a regression (recent or otherwise)
Comment 3 Eclipse Genie CLA 2020-08-19 16:11:13 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 4 Eclipse Genie CLA 2022-11-17 14:29:29 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.