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

Java source parser does not follow Java rules for shadowing.

    Details

      Description

      It's easiest to just look at the attachment in order to understand the problem.

      The Java class my.test.bl.bo.CashDrawer.getDrawer() is returning a type of my.test.bl.bo.location.Drawer. Scala thinks it's returning a type of my.test.bl.bo.Drawer even though CashDrawer specifically imports my.test.bl.bo.location.Drawer.

      CashDrawer.java
      package my.test.bl.bo;
      
      import my.test.bl.bo.location.Drawer;
      
      public class CashDrawer {
          public static Drawer getDrawer() {
              return new Drawer();
          }
      }
      

      Scala will interpret it correctly only if the type names are all fully qualified.

      CashDrawer.java
      package my.test.bl.bo;
      
      public class CashDrawer {
          public static my.test.bl.bo.location.Drawer getDrawer() {
              return new my.test.bl.bo.location.Drawer();
          }
      }
      

        Issue Links

          Activity

          Hide
          Adriaan Moors added a comment -

          Are we talking about scalac parsing java source code? If you're not in the IDE, the best thing to do would be to first compile your Java to class files and then compile with scalac against the class files. It would still be good to fix this, though, of course!

          Show
          Adriaan Moors added a comment - Are we talking about scalac parsing java source code? If you're not in the IDE, the best thing to do would be to first compile your Java to class files and then compile with scalac against the class files. It would still be good to fix this, though, of course!
          Hide
          Joseph Freeman added a comment - - edited

          As far as I know, scalac parses the Java code as well as the Scala code...so I guess it would be scalac that's at fault here.

          It does seem to work if you run the code from within the Eclipse. However, doing 'mvn clean install' in a separate terminal will fail unless the type names are fully qualified every time.

          Also, if I have Java calling Scala and Scala calling Java, then I don't think your suggestion would work. Right?

          Show
          Joseph Freeman added a comment - - edited As far as I know, scalac parses the Java code as well as the Scala code...so I guess it would be scalac that's at fault here. It does seem to work if you run the code from within the Eclipse. However, doing 'mvn clean install' in a separate terminal will fail unless the type names are fully qualified every time. Also, if I have Java calling Scala and Scala calling Java, then I don't think your suggestion would work. Right?
          Show
          Jason Zaugg added a comment - A cut down failing test: https://github.com/retronym/scala/compare/scala:2.10.x...retronym:ticket/7232
          Hide
          Jason Zaugg added a comment -

          This bug is a consequence of scalac reusing the Scala typechecker to analyze Java source files, given the difference binding precedence rules:

          Java Spec:

          A single-type-import declaration d in a compilation unit c of package p that imports
          a type named n shadows, throughout c, the declarations of:
          • any top level type named n declared in another compilation unit of p
          • any type named n imported by a type-import-on-demand declaration in c
          • any type named n imported by a static-import-on-demand declaration in c

          Scala Spec:

          Bindings of different kinds have a precedence defined on them:
          1. Definitions and declarations that are local, inherited, or made available by a
          package clause in the same compilation unit where the definition occurs have
          highest precedence.
          2. Explicit imports have next highest precedence.

          Show
          Jason Zaugg added a comment - This bug is a consequence of scalac reusing the Scala typechecker to analyze Java source files, given the difference binding precedence rules: Java Spec: A single-type-import declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of: • any top level type named n declared in another compilation unit of p • any type named n imported by a type-import-on-demand declaration in c • any type named n imported by a static-import-on-demand declaration in c Scala Spec: Bindings of different kinds have a precedence defined on them: 1. Definitions and declarations that are local, inherited, or made available by a package clause in the same compilation unit where the definition occurs have highest precedence. 2. Explicit imports have next highest precedence.
          Show
          Jason Zaugg added a comment - WIP: https://github.com/retronym/scala/tree/ticket/7232-2
          Hide
          Jason Zaugg added a comment -

          Oh, I just realised the Eugene picked up this ticket earlier today. @Eugene: Let me know if you want me to take it, otherwise feel free to use my branch as a reference. It definitely needs additional test variations.

          Show
          Jason Zaugg added a comment - Oh, I just realised the Eugene picked up this ticket earlier today. @Eugene: Let me know if you want me to take it, otherwise feel free to use my branch as a reference. It definitely needs additional test variations.
          Show
          Jason Zaugg added a comment - https://github.com/scala/scala/pull/2247

            People

            • Assignee:
              Jason Zaugg
              Reporter:
              Joseph Freeman
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development