Imported From: https://issues.scala-lang.org/browse/SI-6640?orig=1
Reporter: @dcsobral
Affected Versions: 2.10.0-RC2
Other Milestones: 2.10.0
Attachments:

• AllBuild.scala (created on Nov 9, 2012 6:58:17 PM UTC, 2360 bytes)
• build.sbt (created on Nov 9, 2012 5:41:49 PM UTC, 193 bytes)
• fulltrace.txt (created on Nov 9, 2012 5:41:49 PM UTC, 15383 bytes)
• ResourceSpec.scala (created on Nov 9, 2012 5:41:49 PM UTC, 243 bytes)
• si6640-miminalProject.zip (created on Nov 9, 2012 10:14:20 PM UTC, 2629 bytes)

@gaydenko said:
Thanks to Daniel Sobral - he has directed me here as far as I have similar issue. Please look at

https://groups.google.com/forum/#!topic/scala-user/FHSlXMklNso

@retronym said:
The cause of the problem is a missing JAR on the classpath.

If you move the mock call to the top level, you get a more accurate error message.

info] Compiling 1 Scala source to /Users/jason/code/scratch1/target/scala-2.10/classes...
[error] bad symbolic reference to class MockSettings in package mockito (a classfile may be missing)
[error] one error found

After adding the following:

libraryDependencies += "org.mockito" % "mockito-all" % "1.9.0"

Both the reduced and originally reported files compile successfully.

But no doubt we should issue this error in both cases. It will be interesting to piece together the circumstances that lead do that assertion error during unpickling.

@dcsobral said:
Glad to know. Downgrade priority?

@retronym said:
I'd still call it critical, this is a huge time waster for people. Not a blocker, although we have to see if Andrew's problem can be solved with an expanded classpath.

@gaydenko said (edited on Nov 9, 2012 6:59:35 PM UTC):
I have attached AllBuild.scala sbt project file. Am not sure how to modify deps. Hints?

@dcsobral said:
Just to make it clear to anyone browsing this ticket, it's not a matter of a "more helpful error message". The compiler crashes instead of producing an error message.

@retronym said:
Andrew: Try this:

~/code/scratch1 diff -u AllBuild.scala AllBuild2.scala 
--- AllBuild.scala	2012-11-09 21:57:00.000000000 +0100
+++ AllBuild2.scala	2012-11-09 21:59:29.000000000 +0100
@@ -10,6 +10,7 @@
   private lazy val mailDep = "javax.mail" % "mail" % "1.4.5"
   private lazy val swingDep = "org.scala-lang" % "scala-swing" % scalaInUse
   private lazy val junitDep = "junit" % "junit" % "4.8.2"
+  private lazy val scalaActorDep = "org.scala-lang" % "scala-actors" % scalaInUse
 
   override lazy val settings = super.settings ++ Seq(
     scalaVersion := scalaInUse,
@@ -29,7 +30,7 @@
 
   lazy val  zgsLib = Project("zgs-lib", file("zgs-kit/zgs-lib")) settings(
     name := "zgs-lib",
-    libraryDependencies ++= Seq(swingDep, mailDep)
+    libraryDependencies ++= Seq(swingDep, mailDep, scalaActorDep)
   )

@gaydenko said:
Modularization in practice :) Jason, thanks, it did. And it is funny I don't use actors. But use swing, and last one does use actors. Ugh..

Daniel, aha, any compiler exception is a compiler bug.

@retronym said:
Andrew: It appears that the references from Scala Swing to scala.actor are really some historical hangover. I've created a ticket to either remove them or fix it's POM to declare a dependency.

Are you by any chance referring to scala.swing.SwingWorker in your code? I'd like to figure out specifically which class you're referring to that brings in this dependency.

@gaydenko said (edited on Nov 9, 2012 10:02:20 PM UTC):
Jason, no, I don't use scala.swing.SwingWorker, but I have own internal wrapper around javax.swing.SwingWorker:

import javax.swing.SwingWorker
import scala.swing._
...

protected class SwiWorker[T](parent : Component, msg : String, job : => Answer[T], showPost : Boolean, 
                  postMsg : String, postJob : Answer[T] => Unit) extends SwingWorker[Answer[T],AnyRef] {
   ...
}

Probably this import list is dangerous at some point: scala.swing package contains SwingWorker also.

@retronym said:
It would be super useful if you could reproduce the problem in a cut-down project with just that one file. I'm not sure how many problems we are really dealing with here.

@gaydenko said:
Jason, sure! Just can't reduce yet. Will try further.

@adriaanm said (edited on Nov 9, 2012 10:22:02 PM UTC):
when running under -Ydebug, I think this may be relevant:

[warn] creating stub symbol for value stubbing in package mockito (a classfile may be missing)

the assertion

java.lang.AssertionError: assertion failed: value stubbing
	at scala.reflect.internal.Types$ThisType.<init>(Types.scala:1388)

fails because we created a StubSymbol hoping that we could keep going a bit longer
except we shouldn't have

@gaydenko said:
It is a minimal project. Commenting out of "import scala.swing._" eliminates the exception.

@adriaanm said:
Thanks, Andrew. I think my comment above pinpoints the problem.

@retronym said:
@andrew; Thanks for the project, that will help me figure whether the Swing to Actors dependency is intentional or an oversight.

@adriaan: I'd suspected that, but couldn't muster the right keywords to find the commit. (Even when the universe was handing it to me on a plate: OP's crasher failed at a package "java.lang.AssertionError: assertion failed: value stubbing"!)

@adriaanm said:
Yeah, a StubSymbol called "stubbing"? You can't make that shit up.

@retronym said (edited on Nov 9, 2012 11:00:24 PM UTC):
@andrew:

Indeed, scala-swing's dependency on scala-actors is an historical accident. I've raised #6441 to remedy this.

Rather than depending on that actors JAR, you could change your code from:

import scala.swing._
import javax.swing.SwingWorker

abstract class SwiWorker[T] extends SwingWorker[T,AnyRef] 

To:

import scala.swing._

abstract class SwiWorker[T] extends javax.swing.SwingWorker[T,AnyRef] 

This will stop the compiler from searching for SwingWorker under the wildcard import scala.swing._.

This would also work:

import scala.swing.{SwingWorker => _, _}
import javax.swing.SwingWorker

abstract class SwiWorker[T] extends SwingWorker[T,AnyRef] 

@gaydenko said:
Jason, thanks! FQN variant is closer to me :)

@retronym said:
scala/scala#1607

@som-snytt said:
I encountered this just doing a random test compile using the partest source, scalac -d junk $(find ./src/partest -name "*.scala"), without ant.jar. Thanks for the fix. I checked it out locally; is the reporting intended to be verbose (56 errors on PartestTask)?