Scala Programming Language
  1. Scala Programming Language
  2. SI-3120

Scala class inheriting a Java class and overriding method with inner class parameter

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None

      Description

      I have this Java class with inner class:

      MyClassWithInner.java:

      public class MyClassWithInner {
          public class MyInnerClass {}
      }
      

      Then another Java class using MyInnerClass:

      MyBaseJavaClass.java:

      public class MyBaseJavaClass {
          public void passInner(MyClassWithInner.MyInnerClass myInner) {}
      }
      

      Finally, this Scala class:

      MyDerivedScalaClass.scala:

      class MyDerivedScalaClass extends MyBaseJavaClass {
          override def passInner(myInner: MyClassWithInner#MyInnerClass) = {}
      }
      

      Compiling:

      scalac scala/.scala java/.java

      java/MyBaseJavaClass.java:2: error: not found: value MyClassWithInner
      public void passInner(MyClassWithInner.MyInnerClass myInner) {}

      Same result with 2.7.7 and 2.8.0.Beta1.

      See this discussion:

      http://comments.gmane.org/gmane.comp.lang.scala.user/24133

        Issue Links

          Activity

          Hide
          Paul Phillips added a comment -

          Sorry, I was going to open this, hadn't gotten to it. Here is the issue. Observe these classes:

          public class J1 {
            public class Inner1 { }
            public static class Inner2 { }
          }
          public class J2 {
            public void f1(J1.Inner1 p) { }
            public void f2(J1.Inner2 p) { }
          }
          public class Q {
            public void passInner(J1.Inner1 myInner) {}
          }
          

          When scala parses the method signatures in J2, it treats them as member selections. In scala we write J1.Inner1 for the static version and J1#Inner1 for the instance, but java offers no such crutch. The reason I couldn't dash off an easy fix is that at the parsing stage it doesn't yet know which it is.

          In JavaParsers I could do this:

          - Select(qual, name.toTypeName)
          + SelectFromTypeTree(convertToTypeId(qual), name.toTypeName)
          

          and in fact that fixes this bug, but then breaks anything that needed the guess to go the other way. So I will need some input on how to defer it long enough to obtain the type information.

          Show
          Paul Phillips added a comment - Sorry, I was going to open this, hadn't gotten to it. Here is the issue. Observe these classes: public class J1 { public class Inner1 { } public static class Inner2 { } } public class J2 { public void f1(J1.Inner1 p) { } public void f2(J1.Inner2 p) { } } public class Q { public void passInner(J1.Inner1 myInner) {} } When scala parses the method signatures in J2, it treats them as member selections. In scala we write J1.Inner1 for the static version and J1#Inner1 for the instance, but java offers no such crutch. The reason I couldn't dash off an easy fix is that at the parsing stage it doesn't yet know which it is. In JavaParsers I could do this: - Select(qual, name.toTypeName) + SelectFromTypeTree(convertToTypeId(qual), name.toTypeName) and in fact that fixes this bug, but then breaks anything that needed the guess to go the other way. So I will need some input on how to defer it long enough to obtain the type information.
          Hide
          Martin Odersky added a comment -

          There's nothing elegant we can do here. The only hack I see is to try first one and then the other when typechecking Java files. I'll try that.

          Show
          Martin Odersky added a comment - There's nothing elegant we can do here. The only hack I see is to try first one and then the other when typechecking Java files. I'll try that.
          Hide
          Martin Odersky added a comment -

          (In r21157) Closes SI-3120. Review by extempore.

          Show
          Martin Odersky added a comment - (In r21157) Closes SI-3120 . Review by extempore.
          Hide
          Erik Bruchez added a comment -

          Excellent, I tried this on the latest trunk and my example now compiles without errors!

          Show
          Erik Bruchez added a comment - Excellent, I tried this on the latest trunk and my example now compiles without errors!

            People

            • Assignee:
              Martin Odersky
              Reporter:
              Erik Bruchez
              TracCC:
              Erik Bruchez, Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development