published 0.1.0 JARs don't work #15
Comments
|
@szeiger is it obvious to you what's going on here? |
|
the published JAR only includes the contents of the |
Closed
SethTisue
pushed a commit
to SethTisue/scala-parallel-collections
that referenced
this issue
Mar 20, 2017
Top level modules in Scala currently desugar as:
```
class C; object O extends C { toString }
```
```
public final class O$ extends C {
public static final O$ MODULE$;
public static {};
Code:
0: new scala#2 // class O$
3: invokespecial scala#12 // Method "<init>":()V
6: return
private O$();
Code:
0: aload_0
1: invokespecial scala#13 // Method C."<init>":()V
4: aload_0
5: putstatic scala#15 // Field MODULE$:LO$;
8: aload_0
9: invokevirtual scala#21 // Method java/lang/Object.toString:()Ljava/lang/String;
12: pop
13: return
}
```
The static initalizer `<clinit>` calls the constructor `<init>`, which
invokes superclass constructor, assigns `MODULE$= this`, and then runs
the remainder of the object's constructor (`toString` in the example
above.)
It turns out that this relies on a bug in the JVM's verifier: assignment to a
static final must occur lexically within the <clinit>, not from within `<init>`
(even if the latter is happens to be called by the former).
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
This relies on the way that we assign MODULE$ field after the super class constructors
are finished, but before the rest of the module constructor is called.
Instead, this commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
We will still achieve safe publication of the assignment to other threads
by virtue of the fact that `<clinit>` is executed within the scope of
an initlization lock, as specified by:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.5
Fixes scala/scala-dev#SD-194
|
Yes, the direct cause is the missing export. I'll fix that. In the long run we need to avoid the split package. It can be used with OSGi but not with Java 9 modules. |
|
0.1.1 release build: https://travis-ci.org/scala/scala-parallel-collections/builds/213641316 |
|
try again after merging #20: https://travis-ci.org/scala/scala-parallel-collections/builds/213646937 |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: