RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell

[Jan Lahoda]

On Mon, 12 Sep 2022 15:15:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output

Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:


$ cat Test.java 
public interface Test {
    default void test(Unknown1 t) {
        Unknown2 tt;
    }
}
$ javac Test.java 
Test.java:2: error: cannot find symbol
    default void test(Unknown1 t) {
                      ^
  symbol:   class Unknown1
  location: interface Test
Test.java:3: error: cannot find symbol
        Unknown2 tt;
        ^
  symbol:   class Unknown2
  location: interface Test
2 errors


I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10221