[javac vs ecj] default method without return isn't reported when there's other compilation errors

[datho7561]

Here's an example:

public interface MyInterface {
	default int foo() {

	}
	int i = foo();
}

javac reports two errors:

1. There's no return statement in the default implementation of foo()
2. foo() is not static, so it can't be called to initialize i

ecj only reports the second error. If the declaration for i is removed completely, then it will report the first error.

[srikanth-sankaran]

Hello David, this is not an invalid defect report, but it is very unlikely to be fixed.

Basically, the error This method must return a result of type int gets issued from the control flow analysis phase of the compiler pipeline which is entered only if prior phases did not trigger any hard errors. The reason we short circuit pipeline stages N+1, N+2 ... when a given stage N has errors is that subjecting a faulty program to further analysis could result in a cascade of additional errors of low quality given the brokenness of the program.

This also means sometimes valid additional errors may not surface until all errors at a pipeline stage is addressed as in this case.

BTW, which version of javac are you testing with:

I find javac exhibits the exact same behavior:

$ cat X.java
public interface X {
    default int foo() {

    }
    int i = foo();
}
$ ~/jdk/jdk-25/jdk-25.0.1/bin/javac -Xlint:unchecked X.java
X.java:5: error: non-static method foo() cannot be referenced from a static context
    int i = foo();
            ^
1 error
$ cat X.java
public interface X {
    default int foo() {

    }
    //int i = foo();
}
$ ~/jdk/jdk-25/jdk-25.0.1/bin/javac -Xlint:unchecked X.java
X.java:4: error: missing return statement
    }
    ^
1 error

[srikanth-sankaran]

I plan to close this as won't fix. I'll wait to give you an opportunity to chime in.

[datho7561]

gets issued from the control flow analysis phase of the compiler pipeline which is entered only if prior phases did not trigger any hard errors

That makes sense why the error isn't reported, and I don't think it makes sense to report given that context.

BTW, which version of javac are you testing with:

Oh yeah oops, we were running javac through the Java API and hacked it to skip aborting compilation. I can't reproduce both errors being reported when running from the command line. I'm guessing the rationale for not reporting the error is the same with javac.

Given we only see both problems reported with a hacked javac, I think it makes sense to close this issue.