Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8194847

javac generates bad code for private method in interface super call

    Details

    • Type: Bug
    • Status: New
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 9, 9.0.4, 10, 11
    • Fix Version/s: 11
    • Component/s: tools
    • Subcomponent:
    • Introduced In Build:
      b54
    • Introduced In Version:
      9
    • CPU:
      generic
    • OS:
      generic

      Description

      FULL PRODUCT VERSION :
      java version "9.0.1"
      Java(TM) SE Runtime Environment (build 9.0.1+11)
      Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)


      ADDITIONAL OS VERSION INFORMATION :
      Darwin Kernel Version 16.7.0: Mon Nov 13 21:56:25 PST 2017; root:xnu-3789.72.11~1/RELEASE_X86_64 x86_64

      A DESCRIPTION OF THE PROBLEM :
      The following code is compiled fine.

      package a;

      public class A {
          public static void main(String[] args) {
              new C().test();
          }

          private interface B {
              private void test() {
              }
          }

          static class C implements B {
              void test() {
                  B.super.test();
              }
          }
      }

      But when you try to run this code, you will receive exception:

      Exception in thread "main" java.lang.NoSuchFieldError: super
      at a.A$C.test(A.java:15)
      at a.A.main(A.java:5)

      Apparently this code should not be compiled, as B.super.test(); construction is improper?


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Take code from description and compile it: javac a/A.java.
      After that run the code:

      bash-3.2$ java a.A
      Exception in thread "main" java.lang.NoSuchFieldError: super
      at a.A$C.test(A.java:15)
      at a.A.main(A.java:5)

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      The code should not be compiled.
      ACTUAL -
      The code compiled fine.

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      Exception in thread "main" java.lang.NoSuchFieldError: super
      at a.A$C.test(A.java:15)
      at a.A.main(A.java:5)

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      public class A {
          public static void main(String[] args) {
              new C().test();
          }

          private interface B {
              private void test() {
              }
          }

          static class C implements B {
              void test() {
                  B.super.test();
              }
          }
      }
      ---------- END SOURCE ----------

      1. A.java
        0.3 kB
        Fairoz Matte

        Issue Links

          Activity

          Hide
          fmatte Fairoz Matte added a comment -
          This issue is not reproducible on 8u162, it is applicable only to 9 and 10. Regression started from 9 ea b54 onwards.
          8u162 - Pass //Compilation error
          9 ea b53 - Pass //Compilation error
          9 ea b54 - Fail //No compilation error, runtime error
          9 GA - Fail
          9.0.4 - Fail
          10 ea b37 - Fail

          Suspecting this is introduced by JDK-8067886
          Show
          fmatte Fairoz Matte added a comment - This issue is not reproducible on 8u162, it is applicable only to 9 and 10. Regression started from 9 ea b54 onwards. 8u162 - Pass //Compilation error 9 ea b53 - Pass //Compilation error 9 ea b54 - Fail //No compilation error, runtime error 9 GA - Fail 9.0.4 - Fail 10 ea b37 - Fail Suspecting this is introduced by JDK-8067886
          Hide
          jjg Jonathan Gibbons added a comment -
          JDK-8067886 is about imports and looks unrelated.
          Show
          jjg Jonathan Gibbons added a comment - JDK-8067886 is about imports and looks unrelated.
          Hide
          mcimadamore Maurizio Cimadamore added a comment - - edited
          A big change in b54 is JDK-8071453. The suggested bug JDK-8067886 does not even appear among the ones integrated in b54. That said, I see nothing in JDK-8071453 that could cause such an issue.
          Show
          mcimadamore Maurizio Cimadamore added a comment - - edited A big change in b54 is JDK-8071453 . The suggested bug JDK-8067886 does not even appear among the ones integrated in b54. That said, I see nothing in JDK-8071453 that could cause such an issue.
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          Actually - this has _all_ to do with JDK-8071453 :-).

          The problem is that the compiler is allowing a default super call on a non-default method. This condition was not possible before since before private methods were added to interfaces, the only kind of instance concrete method available in an interface was, in fact, a default method.
          Show
          mcimadamore Maurizio Cimadamore added a comment - Actually - this has _all_ to do with JDK-8071453 :-). The problem is that the compiler is allowing a default super call on a non-default method. This condition was not possible before since before private methods were added to interfaces, the only kind of instance concrete method available in an interface was, in fact, a default method.
          Hide
          mcimadamore Maurizio Cimadamore added a comment - - edited
          The problem here is that b54 added support for private interface methods. So, while this code was illegal before b54 (as private interface methods were NOT allowed by javac), the code started to compile after b54.

          There are two possible interpretation of what should happen here:

          1) the syntax Type.super.Ident is reserved for default super calls - as such this program should be rejected

          2) the syntax Type.super.Ident is reserved for super interface calls - as such this program should be allowed (and the code generation problem fixed)

          I currently see no basis in the JLS for (1) (see JLS SE 9, section 15.12.3), which seems to suggest that (2) is the way to go. But we need to check as to whether that's deliberate. If (1) is the preferred path, it's likely that a spec change would also be required.
          Show
          mcimadamore Maurizio Cimadamore added a comment - - edited The problem here is that b54 added support for private interface methods. So, while this code was illegal before b54 (as private interface methods were NOT allowed by javac), the code started to compile after b54. There are two possible interpretation of what should happen here: 1) the syntax Type.super.Ident is reserved for default super calls - as such this program should be rejected 2) the syntax Type.super.Ident is reserved for super interface calls - as such this program should be allowed (and the code generation problem fixed) I currently see no basis in the JLS for (1) (see JLS SE 9, section 15.12.3), which seems to suggest that (2) is the way to go. But we need to check as to whether that's deliberate. If (1) is the preferred path, it's likely that a spec change would also be required.
          Hide
          mcimadamore Maurizio Cimadamore added a comment - - edited
          Dropping the regression label - this is not a regression; but a possibly unexpected interaction between a new feature (private interface methods) with an existing feature (default method super calls syntax).
          Show
          mcimadamore Maurizio Cimadamore added a comment - - edited Dropping the regression label - this is not a regression; but a possibly unexpected interaction between a new feature (private interface methods) with an existing feature (default method super calls syntax).
          Hide
          briangoetz Brian Goetz added a comment -
          Our intent in adding the `I.super.m()` syntax was more towards (1).
          Show
          briangoetz Brian Goetz added a comment - Our intent in adding the `I.super.m()` syntax was more towards (1).
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          Targeting 11 as this requires spec work too.
          Show
          mcimadamore Maurizio Cimadamore added a comment - Targeting 11 as this requires spec work too.

            People

            • Assignee:
              Unassigned
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: