support for JVM's visibility modifiers

[scabug]

While Finagle is primarily written in Scala, we support Java users as well. The lack of byte code support for JVM's protected visibility and default (package) visibility is limiting.

We'd love support for these, perhaps via an annotation. A sketch of what it might look like:

import scala.annotation.{Modifier, Visibility}

@Visibility(Modifier.Default)
def method1(): Unit = ()

@Visibility(Modifier.Protected)
def method2(): Unit = ()

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-10174?orig=1
Reporter: Kevin Oliver (kevinoliver)

[scabug]

@adriaanm said:
Yeah, this is something we should support. We're also limited by our lack of expressiveness in the bytecode visibility department, as that is how we define binary compatibility. Not sure I'd go with an annotation (since they're not supposed to influence semantics like that). It's a tricky design problem... We could provide something under a flag as a stopgap.

The problem in compiling visibility to bytecode modifiers when qualifying visibility with a package lies with our notion of package nesting, whereas Java does not consider packages a.foo and a.bar related in any way. For example, this compiles:

package a { private[a] class A }
// [fastforward ten years] you add:
package a.sub { private[a] class B extends a.A } // compiles

To be honest, we've kind of been hoping Java 9's module system would take care of this for us, but I would love to fix this if we can find a reasonable way.

[scabug]

Jasper-M said:
As for protected, aren't protected and protected[this] in scala at least as strict as protected in java?
So in those cases it would be possible to emit a protected modifier?

[scabug]

Kevin Oliver (kevinoliver) said:

The problem in compiling visibility to bytecode modifiers when qualifying visibility with a package lies with our notion of package nesting, whereas Java does not consider packages `a.foo` and `a.bar` related in any way. 

Yep, I totally get that. And I think that is why Scala can't simply translate private[a] into default visibility. Thus my annotation proposal. If there is another keyword or way this can be indicated to Scalac, that'd be great. I'm not at all tied to using annotations. It was intended to be illustrative.

As for protected, aren't protected and protected\[this\] in scala at least as strict as protected in java?
So in those cases it would be possible to emit a protected modifier?

Agreed, I believe it orthogonal to default visibility. My annotation proposal was crafted in the interest of backwards compatibility. As mentioned above, I have zero attachment to it being done this specific way.

Perhaps I should have filed these as separate tickets, but I didn't know enough about the compiler to have a good sense.

[scabug]

@adriaanm said (edited on Feb 9, 2017 10:47:57 PM UTC):
Thanks for clarifying. I'll keep mulling this over. Agreed that any pragmatic solution is better than the status quo!

As for protected, aren't protected and protected[this] in scala at least as strict as protected in java?
Sadly, the same problem regarding package nesting (and companion access) holds here. I'm likely forgetting other snags. There's a large body of tickets on this: https://issues.scala-lang.org/issues/?jql=labels%20%3D%20%22access%22, old mailing list thread (one of many): http://www.scala-lang.org/old/node/8215.html

There's no easy comprehensive fix, but maybe there'll be a good pragmatic compromise. Perhaps using an annotation on the qualifier, such as (the strawman: ) private[C @sealed] to indicate no package nesting / companion access is allowed...