-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Revert @static
annotation
#1340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert @static
annotation
#1340
Conversation
This reverts commit cb393fc. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
This reverts commit 373f22a.
This reverts commit faa114e.
This reverts commit 5a8dfad. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
This reverts commit 2272390.
This reverts commit 892ee3d with exception of keeping `@static` annotation in the library so we can deploy a new starr that does not depend on it before removing it completely. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala src/compiler/scala/tools/nsc/transform/CleanUp.scala
Deployed a new starr that does not depend on `@static` annotation. The next step will be deleting `@static` from the library altogether.
It's a follow-up commit on 4bfcada.
LGTM |
Started jenkins job pr-rangepos at https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/499/ |
Started jenkins job pr-scala-testsuite-linux-opt at https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1207/ |
jenkins job pr-rangepos: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/499/ |
jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1207/ |
Revert `@static` annotation
Hi, is there any further plan for this |
There's been a more recent discussion here: https://groups.google.com/forum/#!searchin/scala-internals/static$20annotation/scala-internals/Y3OlFWPvnyM/tGE5BQw4Pe0J |
the issues discussed there are blockers imo. |
Did anything else ever happen after this discussion? |
Yes @mrebhan. A SIP was created: http://docs.scala-lang.org/sips/pending/static-members.html. The SIP is under implementation since a member of the SIP board volunteered to provide one. This implementation would in theory target 2.12.x. |
yes, see http://docs.scala-lang.org/sips/pending/static-members.html plus it was discussed at a SIP meeting. ordinarily the minutes would be found at http://docs.scala-lang.org/sips/minutes-list.html, but I see that's fallen behind by some months — for now see scala/docs.scala-lang#762 |
I beat you by 1 minute and 37 seconds @SethTisue. You're not as fast as you used to be 😜. |
I spent the extra two minutes finding the minutes PR :-P :-P |
Thanks guys :'D |
Any progress on this feature? |
As of 2.13.0/2.12.9/2.11.12 (the latest versions of each of the last three releases), Scala generates static forwarder methods: // Test.scala
object Test {
val foo: String = "foo"
def bar: String = "bar"
} // javap -c 'Test.class' # compiled with 2.13.0, 2.12.9 or 2.11.12
public final class Test {
public static java.lang.String bar();
Code:
0: getstatic #16 // Field Test$.MODULE$:LTest$;
3: invokevirtual #18 // Method Test$.bar:()Ljava/lang/String;
6: areturn
public static java.lang.String foo();
Code:
0: getstatic #16 // Field Test$.MODULE$:LTest$;
3: invokevirtual #21 // Method Test$.foo:()Ljava/lang/String;
6: areturn
} // javap -c -p 'Test$.class' # compiled with 2.13.0
public final class Test$ {
public static final Test$ MODULE$;
private static final java.lang.String foo;
public static {};
Code:
0: new #2 // class Test$
3: dup
4: invokespecial #14 // Method "<init>":()V
7: putstatic #16 // Field MODULE$:LTest$;
10: ldc #17 // String foo
12: putstatic #19 // Field foo:Ljava/lang/String;
15: return
public java.lang.String foo();
Code:
0: getstatic #19 // Field foo:Ljava/lang/String;
3: areturn
public java.lang.String bar();
Code:
0: ldc #23 // String bar
2: areturn
private Test$();
Code:
0: aload_0
1: invokespecial #24 // Method java/lang/Object."<init>":()V
4: return
} // javap -c -p 'Test$.class' # compiled with 2.12.9
public final class Test$ {
public static Test$ MODULE$;
private final java.lang.String foo;
public static {};
Code:
0: new #2 // class Test$
3: invokespecial #14 // Method "<init>":()V
6: return
public java.lang.String foo();
Code:
0: aload_0
1: getfield #17 // Field foo:Ljava/lang/String;
4: areturn
public java.lang.String bar();
Code:
0: ldc #20 // String bar
2: areturn
private Test$();
Code:
0: aload_0
1: invokespecial #21 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #23 // Field MODULE$:LTest$;
8: aload_0
9: ldc #24 // String foo
11: putfield #17 // Field foo:Ljava/lang/String;
14: return
} // javap -c -p 'Test$.class' # compiled with 2.11.12
public final class Test$ {
public static final Test$ MODULE$;
private final java.lang.String foo;
public static {};
Code:
0: new #2 // class Test$
3: invokespecial #12 // Method "<init>":()V
6: return
public java.lang.String foo();
Code:
0: aload_0
1: getfield #17 // Field foo:Ljava/lang/String;
4: areturn
public java.lang.String bar();
Code:
0: ldc #20 // String bar
2: areturn
private Test$();
Code:
0: aload_0
1: invokespecial #21 // Method java/lang/Object."<init>":()V
4: aload_0
5: putstatic #23 // Field MODULE$:LTest$;
8: aload_0
9: ldc #24 // String foo
11: putfield #17 // Field foo:Ljava/lang/String;
14: return
} |
This commit completes the abstraction over dependency kinds in the incremental compiler, started with scala#1340. Rewritten from sbt/zinc@649168e
Scala 2.13 is out. How do we plan this? |
it's not obvious to me that there's still a need for this. given that the compiler already generates forwarders, what's your use case @HyukjinKwon? |
I would like to define an object that has a static field that can be accessed in Java as well, for example: object Foo {
val field = "abc"
} and in Java side: Foo.field The reason is that to provide the consistent API usages in both Scala and Java. Does it make snese? |
as I mentioned, the compiler generates static forwarders that can be accessed from Java. please see the bytecode showing the static methods in my comment immediately above. while they are methods rather than fields, they still permit access from Java (and are generally considered better practice anyway). |
The point here is to have a field instead of a method in Java side in order to support the same shape of the APIs. I want to support Just allowing a way to access is not enough in particular in APIs. For example, you cannot do such things: object Nations {
object Korea {
def localize = ...
}
val korea = Korea
object US {
def localize = ...
}
val us = US
} In Scala: Nations.us.localize(...) In Java: Nations.us().localize(...) |
that's part of the Uniform Access Principle - that is, it allows you to swap a |
So just to clarify, there's no way to make Java to call |
Correct, there's no way to define a static field in Scala. The proposal for that is SIP-30 (https://docs.scala-lang.org/sips/static-members.html) and it's "under review" but hasn't been discussed recently. I think it lacks both a motivated implementer and a SIP committee champion, at this point. |
This pull request reverts all changes related to
@static
feature.As it has been discussed on scala-internals this feature should come with SIP in the first place. We need much more time hash out the details of
@static
semantics which we don't have at the moment given how close the RC1 is.Review by @axel22.