Imported From: https://issues.scala-lang.org/browse/SI-7926?orig=1
Reporter: @dotta
Affected Versions: 2.11.0-M6

@retronym said:
Do you have a recommendation? Would you like us to offer the better version of fullyInitializeSymbol? Or call that automatically on your behalf somewhere?

@dotta said:
My feeling is that it should be transparent for the user. So, if there is any symbol that have to be initialized, it should be done automatically.

The other question is whether the current implementation of the symbol importers API could be improved to avoid the need of pre-initializing symbols before importing them in a different universe. I don't have enough insights to answer this, but I can imagine doing so may require foundamental changes in the compiler hearth, if possible at all. But the current design seems broken, and fragile. Can you really ensure that you will have initialized enough symbols?
If this is a known limitation, and there is no other way around it, then that's what it is, and we'll live with it.

@retronym said:
Maybe we can discuss a smaller example. Here's a starting point:

class Global(expectedThread: Thread) {
  def checkThread() { Thread.currentThread == expectedThread }
  def set(a: Any) = {checkThread(); ...  }
  lazy val get = {checkThread(); ...  }
}

def importer(g1: Global, g2: Global) = {
  g2.set(g1.get)
}

val g1 = new Global(thread1); val g2 = new Global(thread2)
onThread(thread2) {
  import(g1, g2)
}

Here, importer can never satisfy the checks for the correct thread. As I understand it, you workaround this by:

onThread(thread1) { g1.get }
onThread(thread2) { importer(g1, g2) }

In practice, there are a few more layers; You get Symbols out of Global, and some methods on the Symbol are lazy and need forcing.

Brainstorming solutions, we could:

• find all APIs in the compiler that return a Symbol and decorate them for the presentation compiler with something that calls fullyInitialize
• disable this thread check for the duration of the call to import.
• rewrite Importers to execute calls against g1 and g2 via respectively provided ExecutorServices that do things on the correct thread.
• ???

Let's chat about this tomorrow in person.

@xeno-by said:
I think this issue might be worth taking a second look before releasing 2.11.

@retronym said:
Closing as out of scope as a result of our discussions on this matter didn't find a workable answer,