summaryrefslogtreecommitdiff
path: root/test/files/run/repl-serialization.check
Commit message (Collapse)AuthorAgeFilesLines
* SI-9375 add synthetic readResolve only for static modulesLukas Rytz2015-07-301-1/+0
| | | | | | | | | For inner modules, the synthetic readResolve method would cause the module constructor to be invoked on de-serialization in certain situations. See the discussion in the ticket. Adds a comprehensive test around serializing and de-serializing modules.
* SI-7747 More tests and logic according to our conclusions on #4522.Prashant Sharma2015-06-101-0/+4
|
* SI-7747 Make REPL wrappers serialization friendlyPrashant Sharma2015-05-261-0/+21
Spark has been shipping a forked version of our REPL for sometime. We have been trying to fold the patches back into the mainline so they can defork. This is the last outstanding issue. Consider this REPL session: ``` scala> val x = StdIn.readInt scala> class A(a: Int) scala> serializedAndExecuteRemotely { () => new A(x) } ``` As shown by the enclosed test, the REPL, even with the Spark friendly option `-Yrepl-class-based`, will re-initialize `x` on the remote system. This test simulates this by running a REPL session, and then deserializing the resulting closure into a fresh classloader based on the class files generated by that session. Before this patch, it printed "evaluating x" twice. This is based on the Spark change described: https://github.com/mesos/spark/pull/535#discussion_r3541925 A followup commit will avoid the `val lineN$read = ` part if we import classes or type aliases only. [Original commit from Prashant Sharma, test case from Jason Zaugg]