Add @static SIP

[DarkDimius]

Add @static SIP

[dwijnand]

Comparison

[DarkDimius]

The implementation was merged into Dotty.

[janekdb]

s/7/8/ ?

[kjsingh]

why can't we have static as a keyword?

[sjrd]

Because adding new keywords breaks existing code that used them as identifiers. Adding keywords must be done very sparingly, only when there is no other option.

[kjsingh]

I guess libs doing interop with Java code will be avoiding that.

[jvican]

@DarkDimius is there any change you want to do here before the SIP review?

[DarkDimius]

I guess libs doing interop with Java code will be avoiding that.

Why would they? You may want some data to be seen as Java static field, and you can use @static for this.

[DarkDimius]

@DarkDimius is there any change you want to do here before the SIP review?

@jvican, I've applied those changes now and cleared git history. Feel free to merge if it looks good.

[jvican]

Great changes, let's merge it for next week's discussion.

[xuwei-k]

#635

[adriaanm]

• I don't think it's a good idea to let code gen depend in non-obvious ways on an annotation. Can we break this down further? How about....
  • Always emit object members as class statics, as suggested by Martin (solves initialization mismatch that killed Implement @static annotation on singleton object fields. scala#894, and keeps static members out of class, which would be problematic in our type system)
  • Deal with name clashes using an @exportedName annotation?
  • Allow emitting a public static field without accessor using @suppressAccessors?

The proposal should go into more detail on:

• What about binary compat (adding/removing @static annotation)
• Interaction with initialization semantics?

Some relevant bugs:

• https://issues.scala-lang.org/browse/SI-6189
• https://issues.scala-lang.org/browse/SI-6294
• https://issues.scala-lang.org/browse/SI-6236

[retronym]

I'd like to see the "Compilation scheme" section fleshed out. Currently, it talks about how this would fit into the compiler pipeline, but lacks details about how things would be compiled to bytecode.

Here's an example I'm interested in:

package p1;  object C { @static val foo: AnyRef = C; val bar: AnyRef = C }

If I translate this according to the intuitive description herein, taking a few guesses at the details, I start with:

public class Test {
  public static void main(String[] args) {
    System.out.println(C$.MODULE$.foo()); // null
  }
}

class C {
  public static final Object foo;
  static {
    foo = C$.MODULE$; // initializer moved to CompanionClass.<clinit>
  }
}
final class C$ {
  public static C$ MODULE$;
  private final Object bar;
  public static Object foo() { return C.foo; }
  static {
     Object x = C.foo; // or UNSAFE.ensureClassInitialized(classOf[C])
     new C$();
  }
  private C$() {
    super();
    MODULE$ = this;
    bar = this;
  }
}

Running this prints null. I guess we should move the call to C.<init> after the super constructor call and the assignment of the module var:

final class C$ {
  public static C$ MODULE$;
  private final Object bar;
  public static Object foo() { return C.foo; }
  static {
     new C$();
  }
  private C$() {
    super();
    MODULE$ = this;
    Object x = C.foo; // or UNSAFE.ensureClassInitialized(classOf[C])
    bar = this;
  }
}

Which avoids the NPE.

But in that case, triggering C.<clinit> before C$.<clinit> would reverse the order that the initalizer for foo and the super constructor of the module class is run.

Both of these variations have another drawback: References to C in the RHS of static initializers introduce a cyclic dependency between C.<clinit> and C$.<clinit>. This is deadlock prone if a a pair of threads simultaneously statically initialize the class and module class.

So maybe we instead should put leave all the initalization code in the module class?

class C {
  public static Object foo; // can't be final
}
final class C$ {
  public static C$ MODULE$;
  private final Object bar;
  public static Object foo() { return C.foo; }
  static {
     new C$();
  }
  private C$() {
    super();
    MODULE$ = this;
    C.foo = this;
    bar = this;
  }
}

This looks more promising for thread-safe initialization, and preserving semantics. But we are no unable to declare foo as final, which is a bit of a drag, because one reason you want to make a field static is to hold a method handle "constant", and hotspot only is able to fully inline invocations through that handle if the field is marked final. (Or, if it has the JDK internal annotation, java.lang.invoke.Stable, which isn't in our box of tricks.)

[lrytz]

We could also consider omitting the accessor methods for @static fields and emitting direct accesses to the field.

[DarkDimius]

class C {
  public static Object foo;
  static {
    foo = C$.MODULE$;
  }
}
final class C$ {
  public static C$ MODULE$;
  private final Object bar;
  public static Object foo() { return C.foo; }
  static {
     new C$();
  }
  private C$() {
    super();
    MODULE$ = this;
    Object x = C.foo; // or UNSAFE.ensureClassInitialized(classOf[C])
    bar = this;
  }
}

Is the proposed desugaring.

@retronym

I guess we should move the call to C.<init> after the super constructor call and the assignment of the module var:

I guess you've meant C.<clinit>. Than that's true.

But in that case, triggering C.<clinit> before C$.<clinit> would reverse the order that the initalizer for foo and the super constructor of the module class is run.

C$.<clinit> isn't user defined. Did you mean C$.<init>?

In case you did, the order in which initializer for foo and the super constructor of the module class is run indeed may change under the proposed sip. It's discussed here https://github.com/scala/scala.github.com/pull/658/files#diff-9284321b7900073f358a16a971c06881R159 , do you want me to expand this discussion?

This is deadlock prone if a a pair of threads simultaneously statically initialize the class and module class.

If we always trigger initialization of C.<clinit> from C$.<init> we will introduce ordering here that should help. But in case user-code inherently has cycles in inititaliziation, I don't think we can do anything.

Thanks for the questions, I'll expand the "Compilation scheme" section.

[retronym]

do you want me to expand this discussion?

Yes, it would be useful to talk about the super constructor thing explicitly,
perhaps with an example showing how the order could vary depending on how
whether the class or module was initialized first.

If we always trigger initialization of C. from C$. we will
introduce ordering here that should help. But in case user-code inherently
has cycles in inititaliziation, I don't think we can do anything.

I still think that we're introducing a new form of cycle by moving
the code into 'C$'-s static initializer, but I guess that's what the user
is asking for with this annotation, so we can argue that it is the user's
responsibility to code around this possibility.

[kjsingh]

shouldn't this be final?

[SethTisue]

yes