Expectedly, the following initialisation order without lazy val throws null pointer exception
class Foo {
Bar.x // NullPointerException
}
object Bar extends Foo {
val x = 42
}
object Hello extends App {
Bar
}
Examining -Xprint:jvm output, and referencing #paradigmatic answer, we see this is due to Foo's constructor running first and calling Bar.x() before Bar.this.x is initialised in Bar's constructor:
class Foo extends Object {
def <init>(): example.Foo = {
Foo.super.<init>();
Bar.x();
()
}
};
object Bar extends example.Foo {
private[this] val x: Int = _;
<stable> <accessor> def x(): Int = Bar.this.x;
def <init>(): example.Bar.type = {
Bar.super.<init>();
Bar.this.x = 42;
()
}
};
However, why is null pointer also thrown when x is lazy like so
object Bar extends Foo {
lazy val x = 42
}
Analysing -Xprint:jvm output in lazy case we have
class Foo extends Object {
def <init>(): example.Foo = {
Foo.super.<init>();
Bar.x();
()
}
};
object Bar extends example.Foo {
final <synthetic> lazy private[this] var x: Int = _;
#volatile private[this] var bitmap$0: Boolean = _;
private def x$lzycompute(): Int = {
Bar.this.synchronized(if (Bar.this.bitmap$0.unary_!())
{
Bar.this.x = (42: Int);
Bar.this.bitmap$0 = true
});
Bar.this.x
};
<stable> <accessor> lazy def x(): Int = if (Bar.this.bitmap$0.unary_!())
Bar.this.x$lzycompute()
else
Bar.this.x;
def <init>(): example.Bar.type = {
Bar.super.<init>();
()
}
};
where it seems to me it should work due to the bitmap$0 guard
<stable> <accessor> lazy def x(): Int = if (Bar.this.bitmap$0.unary_!())
Bar.this.x$lzycompute()
else
Bar.this.x;
Runtime field accessors check -Xcheckinit seems to be satisfied on my machine with Scala 2.12.8, so why NullPointerException when lazy val x?
I don't think this NPE is related to val at all. Check this:
class Foo {
Bar.anyMethod
}
object Bar extends Foo {
def anyMethod = ???
}
object Hello extends App {
Bar
}
//java.lang.NullPointerException
Foo is trying to run constructor on Bar while Bar is still under construction. So that's what your Foo is doing too before calling x.
Btw if you put everything into Hello with main method you will get StackOverflow instead of NPE in both mine and your cases.
object Hello {
def main(args: Array[String]): Unit = {
class Foo {
Bar.anyMethod
}
object Bar extends Foo { //<- Bar is like local val now instead of field
def anyMethod= ??? // of package object, so stack is available now.
}
Bar
}
}
Related
Assuming no multiple inheritance and no concerns about interoperability with Java, are the two following declarations equal?
sealed trait Foo { def x: Int }
case object Bar extends Foo { val x = 5 }
and
sealed abstract class Foo(val x: Int)
case object Bar extends Foo(5)
First, some modifications to your code (see below). I dropped the case as it is not relevant here. I also added val in the constructor of Foo2 as x is otherwise not accessible in Bar2.
sealed trait Foo { def x: Int }
object Bar extends Foo { val x = 5 }
sealed abstract class Foo2(val x: Int)
object Bar2 extends Foo2(5)
object Main {
def main(args: Array[String]) : Unit = {
println( Bar.x )
println( Bar2.x )
}
}
Are the two following declarations equal?
We need to define, what equal means:
Equal wrt. general structure: No. A trait is not an abstract class. A trait can have no constructor parameters, while a class can. On the other hand, a class or object (here Bar2) can only derive from one (abstract) class, while it could mix-in multiple traits. A good comprehesion on traits vs. abstract class is given here: http://www.artima.com/pins1ed/traits.html#12.7 if you need to decide on a trait or a class.
Equal wrt. byte code: No. Just run javap -v <classfile> to convince yourself
Equal wrt. Bar and Bar2 only: Yes. Both can be accessed and used identically. Both are singletons and they expose a member variable x that is readable (but not writable) from outside.
Also the output of scalac -print is quite helpful, to see what is going on:
sealed abstract trait Foo extends Object {
def x(): Int
};
object Bar extends Object with com.Foo {
private[this] val x: Int = _;
<stable> <accessor> def x(): Int = Bar.this.x;
def <init>(): com.Bar.type = {
Bar.super.<init>();
Bar.this.x = 5;
()
}
};
sealed abstract class Foo2 extends Object {
<paramaccessor> private[this] val x: Int = _;
<stable> <accessor> <paramaccessor> def x(): Int = Foo2.this.x;
def <init>(x: Int): com.Foo2 = {
Foo2.this.x = x;
Foo2.super.<init>();
()
}
};
object Bar2 extends com.Foo2 {
def <init>(): com.Bar2.type = {
Bar2.super.<init>(5);
()
}
};
object Main extends Object {
def main(args: Array[String]): Unit = {
scala.this.Predef.println(scala.Int.box(Bar.x()));
scala.this.Predef.println(scala.Int.box(Bar2.x()))
};
def <init>(): com.Main.type = {
Main.super.<init>();
()
}
}
No, these are not equivalent and can lead to trouble later with initialization order. I've added exactly the same line of code to each, showing they were never equal code blocks.
sealed trait Foo {
def x: Int
val calc = x * 5 / 2 //at the time this runs, x is actually 0
}
case object Bar extends Foo {
val x = 5
}
sealed abstract class Foo2(x: Int){
val calc = x * 5 / 2
}
case object Bar2 extends Foo2(5)
println(Bar.calc)
println(Bar2.calc)
//output 0 12
I have trimmed my code down to the following. I am confused why I am getting a stack overflow between the two filter methods (one in my trait and one in my superclass)
object TestingOutTraits {
val TestHandler = new Object with MySuper with MyTrait {
override lazy val createdFilter = {
"second part"
}
}
def main(args: Array[String]) = {
val result : String = TestHandler.start()
System.out.println("result="+result)
}
}
trait MySuper {
protected def filter: String = {
"first part to->"
}
def start() = {
filter
}
}
trait MyTrait { self: MySuper =>
lazy val createdFilter = {
"override this"
}
protected override def filter: String = {
self.filter + createdFilter
}
}
This is scala 2.9. Any ideas what is going on here?
EDIT:
The stack trace makes no sense on how it jumps back and forth too(I should have included it in original post)...
at MyTrait$class.filter(TestingOutTraits.scala:34)
at TestingOutTraits$$anon$1.filter(TestingOutTraits.scala:4)
at MyTrait$class.filter(TestingOutTraits.scala:34)
at TestingOutTraits$$anon$1.filter(TestingOutTraits.scala:4)
thanks,
Dean
The call self.filter in MyTrait.filter invokes itself, leading to infinite recursion that blows the stack.
Instead, have MyTrait extend MySuper, and use super.filter:
trait MyTrait extends MySuper {
lazy val createdFilter = {
"override this"
}
protected override def filter: String = {
super.filter + createdFilter
}
}
Alternatively,
trait MySuper extends Filtered {
protected def filter: String = {
"first part to->"
}
def start() = {
filter
}
}
trait Filtered {
protected def filter: String
}
trait MyTrait extends Filtered {
lazy val createdFilter = {
"override this"
}
protected abstract override def filter: String = {
super.filter + createdFilter
}
}
then
val nope = new MyTrait { } // correctly DNC
and the OP
val TestHandler = new MySuper with MyTrait {
override lazy val createdFilter = {
"second part"
}
}
http://www.artima.com/pins1ed/traits.html#12.5
Well, I know why the infinite recursion though this seems like a linearization bug in scala and I am not sure how to work around it yet either :(.
hmmmm, so it turns out the compiler is sticking a filter method in my new Object for some reason. I found this out with the print:mixin on scalac like so
$ scalac -Xprint:mixin TestingOutTraits.scala
[[syntax trees at end of mixin]]// Scala source: TestingOutTraits.scala
package <empty> {
final object TestingOutTraits extends java.lang.Object with ScalaObject {
private[this] val TestHandler: MySuper = _;
<stable> <accessor> def TestHandler(): MySuper = TestingOutTraits.this.TestHandler;
def main(args: Array[java.lang.String]): Unit = {
val result: java.lang.String = TestingOutTraits.this.TestHandler().start();
java.this.lang.System.out.println("result=".+(result))
};
def this(): object TestingOutTraits = {
TestingOutTraits.super.this();
TestingOutTraits.this.TestHandler = {
new anonymous class TestingOutTraits$$anon$1()
};
()
}
};
abstract trait MySuper extends java.lang.Object with ScalaObject {
def filter(): java.lang.String;
def start(): java.lang.String
};
abstract trait MyTrait extends java.lang.Object with ScalaObject { self: MyTrait =>
def createdFilter(): java.lang.String;
override def filter(): java.lang.String
};
abstract trait MySuper$class extends {
def filter($this: MySuper): java.lang.String = "first part to->";
def start($this: MySuper): java.lang.String = $this.filter();
def /*MySuper$class*/$init$($this: MySuper): Unit = {
()
}
};
abstract trait MyTrait$class extends { self: MyTrait =>
def createdFilter($this: MyTrait): java.lang.String = "override this";
override def filter($this: MyTrait): java.lang.String = $this.$asInstanceOf[MySuper]().filter().+($this.createdFilter());
def /*MyTrait$class*/$init$($this: MyTrait): Unit = {
()
}
};
final class TestingOutTraits$$anon$1 extends java.lang.Object with MySuper with MyTrait {
override def filter(): java.lang.String = MyTrait$class.filter(TestingOutTraits$$anon$1.this);
def start(): java.lang.String = MySuper$class.start(TestingOutTraits$$anon$1.this);
override def createdFilter(): java.lang.String = "second part";
def this(): anonymous class TestingOutTraits$$anon$1 = {
TestingOutTraits$$anon$1.super.this();
MySuper$class./*MySuper$class*/$init$(TestingOutTraits$$anon$1.this);
MyTrait$class./*MyTrait$class*/$init$(TestingOutTraits$$anon$1.this);
()
}
}
Considering this simple example:
trait A { def a: String = "a"; def a2: String }
case class C(b: String, c: String) extends A {
val a2 = "a2"
}
val c = C("b", "")
val copy = c.copy(c="c")
When I update field c with .copy(c="c"), are other fields(a,a2 and b) copied? Event though only their references are copied, if I have a huge hierarchy tree, will .copy become very costly?
Similarly:
class Foo {
val list = List(1,2,3,4,5,6)
}
val foo1 = new Foo
val foo2 = new Foo
Do foo1 and foo2 share an instance of List, or every time I instantiate a Foo it creates a new List? What if list is a var instead of val?
Generally Scala is immutable, you usually have to handle mutable cases yourself. Also case classes are immutable by nature and their copy method is generated by the compiler. So yes, they would share the same object reference. This is one of the reasons immutability is nice.
Your second question is a bit different. In that case the classes are constructed one after the other in seperate contexts.
It's also a good idea to check what's being compiled:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
class Foo extends Object {
private[this] val list: List = _;
<stable> <accessor> def list(): List = Foo.this.list;
def <init>(): b.Foo = {
Foo.super.<init>();
Foo.this.list = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
}
}
From this we can see Scala creating a new list each time. Changing this to var won't change anything, we can check:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
class Foo extends Object {
private[this] var list: List = _;
<accessor> def list(): List = Foo.this.list;
<accessor> def list_=(x$1: List): Unit = Foo.this.list = x$1;
def <init>(): b.Foo = {
Foo.super.<init>();
Foo.this.list = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
}
}
It only generated a setter method for it (def list_=(x$1: List)).
If you would like to reference the same list in both cases then initialize it with an object's default list:
object Foo {
val DefaultList = List(1,2,3,4,5,6)
}
class Foo {
var list = Foo.DefaultList
}
Which compiles to the following:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
object Foo extends Object {
private[this] val DefaultList: List = _;
<stable> <accessor> def DefaultList(): List = Foo.this.DefaultList;
def <init>(): test.Foo.type = {
Foo.super.<init>();
Foo.this.DefaultList = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
};
class Foo extends Object {
private[this] var list: List = _;
<accessor> def list(): List = Foo.this.list;
<accessor> def list_=(x$1: List): Unit = Foo.this.list = x$1;
def <init>(): test.Foo = {
Foo.super.<init>();
Foo.this.list = Foo.DefaultList();
()
}
}
}
As you can see the list is only created once and then the reference through the def DefaultList(): List assigned on each Foo class instantiation.
To answer my own first question:
The concrete vals in a trait are implemented as a Java static method:
// scala
trait A { def a: String = "a"; }
// java
public static java.lang.String a(A);
Code:
0: ldc #8 // String a
2: areturn
Of course, a static method can't be copied. So I don't need to worry about huge hierarchy tree.
The abstract val is implemented as a hard-coded constant:
// scala
trait B { def b: String }
case class C() { def b = "b" }
// java
public java.lang.String b();
Code:
0: ldc #47 // String b
2: areturn
It's fine as well.
The only thing(s) will be copied when I call .copy() are the fields in constructor parameter list.
I've seen the args.foreach(arg => println(arg)), but when I search the doc http://www.scala-lang.org/api/current/index.html#scala.Array . I don't find it there and its companion object doc.
Any advice?
Thanks
Array gets operations such as foreach from scala.collection.mutable.ArrayOps - so you can lookup ArrayOps in the documentation to see what methods are available on arrays.
Predef contains a number of implicit conversion methods to make these available for arrays.
Unfortunately you can't see in the Scala API documentation for Array that these methods are available via the implicits in Predef.
As Jesper said, it's not really easy to find documentation on methods acquired via implicit conversions.
The ones defined for Array and the rationale behind them are explained here.
One (not particularly handy...) general way of finding out where a particular method comes from (in cases like yours, where it comes from an implicit conversion) is to use the -print option of the scala REPL.
If you run scala -print you will get:
scala> Array(1,2,3,4)
// ..... omitted for brevity
res0: Array[Int] = Array(1, 2, 3, 4)
scala> res0 foreach (println)
[[syntax trees at end of cleanup]]// Scala source: <console>
package $line2 {
final object $read extends java.lang.Object with ScalaObject {
def this(): object $line2.$read = {
$read.super.this();
()
}
};
#SerialVersionUID(0) final <synthetic> class $read$$iw$$iw$$anonfun$1 extends
scala.runtime.AbstractFunction1 with Serializable {
final def apply(x: java.lang.Object): Unit = scala.this.Predef.println(x);
final <bridge> def apply(v1: java.lang.Object): java.lang.Object = {
$read$$iw$$iw$$anonfun$1.this.apply(v1);
scala.runtime.BoxedUnit.UNIT
};
def this(): anonymous class $read$$iw$$iw$$anonfun$1 = {
$read$$iw$$iw$$anonfun$1.super.this();
()
}
};
final object $read$$iw$$iw extends java.lang.Object with ScalaObject {
private[this] val res1: scala.runtime.BoxedUnit = _;
<stable> <accessor> def res1(): Unit = ();
def this(): object $line2.$read$$iw$$iw = {
$read$$iw$$iw.super.this();
$read$$iw$$iw.this.res1 = {
scala.this.Predef.intArrayOps($line1.$read$$iw$$iw.res0()).foreach({
{
(new anonymous class $read$$iw$$iw$$anonfun$1(): Function1)
}
});
scala.runtime.BoxedUnit.UNIT
};
()
}
};
final object $read$$iw extends java.lang.Object with ScalaObject {
def this(): object $line2.$read$$iw = {
$read$$iw.super.this();
()
}
}
}
[[syntax trees at end of cleanup]]// Scala source: <console>
package $line2 {
final object $eval extends java.lang.Object with ScalaObject {
#volatile protected var bitmap$0: Int = 0;
<stable> <accessor> lazy def $result(): Unit = {
if ($eval.this.bitmap$0.&(1).==(0))
{
$eval.this.synchronized({
if ($eval.this.bitmap$0.&(1).==(0))
{
{
$eval.this.$print();
$line2.$read$$iw$$iw.res1()
};
$eval.this.bitmap$0 = $eval.this.bitmap$0.|(1);
()
};
scala.runtime.BoxedUnit.UNIT
});
()
};
()
};
private[this] val $print: java.lang.String = _;
<stable> <accessor> def $print(): java.lang.String = $eval.this.$print;
def this(): object $line2.$eval = {
$eval.super.this();
$eval.this.$print = {
$line2.$read$$iw$$iw;
""
};
()
}
}
}
1
2
3
4
If you look for .foreach inside this code, you will find the relevant line, that tells you the method is actually called on intArrayOps:
scala.this.Predef.intArrayOps($line1.$read$$iw$$iw.res0()).foreach(
I define a class with abstract type as follow:
abstract class AbsCell2{
type T
val init: T
private var value: T = {
println("Hello "+init);
init
}
def get : T = value
def set(x : T) = { value = x}
}
Now I instantiate an object with type Int
scala> val cell = new AbsCell2{type T = Int ; val init = 10}
Hello 0
cell: AbsCell2{type T = Int} = $anon$1#969ebb
Pay attention to the output from println. It seams the variable init hasn't been initialized as 10. Note that the version of scala is 2.9.0-1
I think you're looking for Scala's early initializers,
scala> val cell = new {type T = Int ; val init = 10} with AbsCell2
Hello 10
cell: AbsCell2{val init: Int; type T = Int} = $anon$1#1efa9557
scala> cell.get
res0: cell.T = 10
Early initializers allow you to allocate a new object and set some specific fields before the class constructor runs. In this case, since value depends on init, we use the early initializer syntax (new { val init = ... } with AbsCell2) to first set init so that the class constructor can properly initialize value.
See also this question: In Scala, what is an "early initializer"?
Change from val to def:
abstract class AbsCell2{
type T
def init: T
private var value: T = {
println("Hello "+init);
init
}
def get : T = value
def set(x : T) = { value = x}
}
It works as expected:
scala> val cell = new AbsCell2{type T = Int ; def init = 10}
Hello 10
cell: AbsCell2{type T = Int} = $anon$1#4302df5
For question about difference between new { type T = Int ; val init = 10 } with AbsCell2 and new AbsCell2 { type T = Int ; val init = 10 }。
The first one is the so-called early-initializers or pre-initialized fields(mentioned in Abstract Members chapter in Programming In Scala)。It allows the subclass to initialize fields before the super class is called。
In this case, init has already been set as 10 before the initialization of AbsCell2。
The latter one is normal inheritance, it creates an anonymous class then extends AbsCell2, just like:
class AbsCell' extends AbsCell {
type T = Int
val init = 10
}
However, the anonymous class gets initialized after the abstract class AbsCell2, so init are not available in the initialization of itself, namely, init is the default value of the Type, 0 in this case. Therefore, you get 0 in the print。
use scalac -Xprint:all Test.scala, you will see the following:
abstract class AbsCell2 extends Object {
<stable> <accessor> def init(): Object;
....
def <init>(): AbsCell2 = {
AbsCell2.super.<init>();
AbsCell2.this.value = {
scala.this.Predef.println("Hello ".+(AbsCell2.this.init()));
AbsCell2.this.init()
};
()
}
};
// normal initialization
final class anon$1 extends AbsCell2 {
private[this] val init: Int = _;
<stable> <accessor> def init(): Int = anon$1.this.init;
....
def <init>(): <$anon: AbsCell2> = {
anon$1.super.<init>();
anon$1.this.init = 10;
()
}
};
// early initialization
final class anon$2 extends AbsCell2 {
private[this] val init: Int = _;
<stable> <accessor> def init(): Int = anon$2.this.init;
....
def <init>(): <$anon: AbsCell2> = {
val init: Int = 10;
anon$2.this.init = init;
anon$2.super.<init>();
()
}
}
From the code, we can see that for normal initialization, init is set to 3 after the initialization of super class AbsCell2, when AbsCell2.this.init() gets invoked, it actually refers to the subclass' init field and 3 is yet to set, so we get the default type value。On the contrary, early initialization first set init to 3 then call super class initialization。