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

Private member of jointly compiled java class is importable.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None
    • Environment:

      java import private visibility

      Description

      A private member of a Java class, whose source is jointly compiled by scalac, is considered importable. If the java file is precompiled with javac and included on the classpath of scalac, it is no longer importable.

      (I raised this on scala-user, but didn't get a reply.)

      E:\code\scratch\access>cat HasPrivateFoo.java
      class HasPrivateFoo {
         private Object foo = null;
      }
      E:\code\scratch\access>cat Import.scala
      object Import {
         def test(foo: Any, h: HasPrivateFoo) {
            import h._
            foo
         }
      }
      
      E:\code\scratch\access>scalac -version
      Scala compiler version 2.8.0.Beta1-prerelease -- Copyright 2002-2010, LAMP/EPFL
      
      E:\code\scratch\access>javac HasPrivateFoo.java
      
      E:\code\scratch\access>scalac -classpath . Import.scala
      
      E:\code\scratch\access>scalac Import.scala HasPrivateFoo.java
      Import.scala:4: error: reference to foo is ambiguous;
      it is both defined in method test and imported subsequently by
      import h._
            foo
            ^
      one error found
      
      E:\code\scratch\access>scalac -version
      Scala compiler version 2.8.0.Beta1-prerelease -- Copyright 2002-2010, LAMP/EPFL
      
      E:\code\scratch\access>rm *class
      
      E:\code\scratch\access>E:\tools\scala-2.8.0.r21113-b20100309020141\bin\scalac Import.scala HasPrivateFoo.java
      Import.scala:4: error: reference to foo is ambiguous;
      it is both defined in method test and imported subsequently by
      import h._
            foo
            ^
      one error found
      

        Issue Links

          Activity

          Hide
          Aleksandar Prokopec added a comment -

          Is it ok to assign this to you, Miles? The fix is not very urgent.

          Thanks

          Show
          Aleksandar Prokopec added a comment - Is it ok to assign this to you, Miles? The fix is not very urgent. Thanks
          Hide
          Miles Sabin added a comment -

          Sure ... I'll see what I can do.

          Show
          Miles Sabin added a comment - Sure ... I'll see what I can do.
          Hide
          Paul Phillips added a comment -

          See also SI-2133 (and SI-3285 which I just closed as duplicate of that.)

          Show
          Paul Phillips added a comment - See also SI-2133 (and SI-3285 which I just closed as duplicate of that.)
          Hide
          Paul Phillips added a comment -

          Based on the resolution of SI-2133, this isn't even a bug unless there will
          be different rules for java. Martin said:

          Stephane's original example is not covered by the spec, which says that
          all importable members are counted. A member is importable as long as
          it is not private[this]. Why this wording? Because an inner class might
          validly import the private members of its companion object.  
          

          That would be a distressing outcome, and not just for this. It seems like we shouldn't have to pollute the namespace of everyone who imports a package with a bunch of inaccessible symbols, just to keep the door open for some hypothetical inner classes.

          Also, see previous ticket of mine SI-3836, "ambiguous references which aren't." But it's worse than I had realized at the time. You can't even use aliases in your own package, private to your own package, without ruining the package.

          package object foo {
            private[foo] type InputStream = java.io.InputStream
            // oddly there is no conflict if there's no qualifier,
            // though the quote from martin would imply otherwise.
            // private type InputStream = java.io.InputStream
          }
          
          object bar {
            import foo._
            import java.io._
          
            var x: InputStream = null
          }
          
          // 9: error: reference to InputStream is ambiguous;
          // it is imported twice in the same scope by
          // import java.io._
          // and import foo._
          //   var x: InputStream = null
          //          ^
          // one error found
          

          I think this is terribly unfortunate. And should be treated as an
          encapsulation failure, not a mere inconvenience (though it is quite
          inconvenient.)

          In the wontfix for SI-3836 martin says he doesn't want name lookup to start intruding on symbol resolution and typing. That's fine. I see this as like implicit resolution or type inference, where there is often some ambiguity which would be resolved if the process continued. An implicit is ruled out because the type parameters don't match its bounds, etc.

          But the biggest thing is that private names which affect an unrelated class's namespace cannot really be called private.

          Show
          Paul Phillips added a comment - Based on the resolution of SI-2133 , this isn't even a bug unless there will be different rules for java. Martin said: Stephane's original example is not covered by the spec, which says that all importable members are counted. A member is importable as long as it is not private[this]. Why this wording? Because an inner class might validly import the private members of its companion object. That would be a distressing outcome, and not just for this. It seems like we shouldn't have to pollute the namespace of everyone who imports a package with a bunch of inaccessible symbols, just to keep the door open for some hypothetical inner classes. Also, see previous ticket of mine SI-3836 , "ambiguous references which aren't." But it's worse than I had realized at the time. You can't even use aliases in your own package, private to your own package, without ruining the package. package object foo { private[foo] type InputStream = java.io.InputStream // oddly there is no conflict if there's no qualifier, // though the quote from martin would imply otherwise. // private type InputStream = java.io.InputStream } object bar { import foo._ import java.io._ var x: InputStream = null } // 9: error: reference to InputStream is ambiguous; // it is imported twice in the same scope by // import java.io._ // and import foo._ // var x: InputStream = null // ^ // one error found I think this is terribly unfortunate. And should be treated as an encapsulation failure, not a mere inconvenience (though it is quite inconvenient.) In the wontfix for SI-3836 martin says he doesn't want name lookup to start intruding on symbol resolution and typing. That's fine. I see this as like implicit resolution or type inference, where there is often some ambiguity which would be resolved if the process continued. An implicit is ruled out because the type parameters don't match its bounds, etc. But the biggest thing is that private names which affect an unrelated class's namespace cannot really be called private.
          Hide
          Paolo G. Giarrusso added a comment - - edited

          Paul, before reading your comment, I added a comment to SI-2133, where I also complained (for the same reasons you give above about failure of encapsulation), and reopened that bug:
          https://issues.scala-lang.org/browse/SI-2133?focusedCommentId=56541#comment-56541
          The reasons you give above seem more valid, so maybe you should close the bug again. Sorry for the noise!

          Show
          Paolo G. Giarrusso added a comment - - edited Paul, before reading your comment, I added a comment to SI-2133 , where I also complained (for the same reasons you give above about failure of encapsulation), and reopened that bug: https://issues.scala-lang.org/browse/SI-2133?focusedCommentId=56541#comment-56541 The reasons you give above seem more valid, so maybe you should close the bug again. Sorry for the noise!

            People

            • Assignee:
              Martin Odersky
              Reporter:
              Jason Zaugg
              TracCC:
              Johannes Rudolph, Mark Harrah, Paul Phillips, Seth Tisue
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development