Scala 2.8.1 IDE bug, Eclipse 3.5 and 3.6.1 (FIXED, SORT OF)

November 11, 2010

FIXED, REALLY in Scala 2.9.0RC1 and corresponding version of Scala-IDE. No more crashes, fast-ish rebuilds, no deadlocks. This is much nicer. A little better with its memory consumption, too.

FIXED IN http://download.scala-ide.org/nightly-update-wip-experiment-trunk (This is a nightly build, based on latest as 2011-02-22, Scala 2.9.)
Unfortunately, this version of the plugin takes 7 times longer (45-50 minutes) to perform a from-scratch project rebuild, and incremental changes are just as costly as clean rebuilds. This is clearly not usable.

Looks like a dupe of #1000150, which is apparently “Invalid”. Not for me.

No earthly idea how to get “Assembla” to let me file a big or attach any information to the bug report, which is why I am writing it all down here.


java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -keyring /Users/dr2chase/.eclipse_keyring -showlocation
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -keyring /Users/dr2chase/.eclipse_keyring -showlocation


java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.initializeTypeVariable(BinaryTypeBinding.java:944)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createTypeVariables(BinaryTypeBinding.java:647)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:484)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:598)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:329)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:674)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:653)
at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:108)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:851)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:100)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:1047)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getMethods(BinaryTypeBinding.java:918)
at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1227)
at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1198)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2258)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:403)
at org.eclipse.jdt.internal.compiler.ast.Assignment.resolveType(Assignment.java:157)
at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:915)
at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90)
at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:264)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:451)
at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:212)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:410)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1147)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1235)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:540)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:759)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:680)

The input that made this happen was the Fortress source code.

It was suggested that perhaps this was caused by a version mismatch. I checked, and apparently it was not, but it took 40 minutes to check this (uninstall old, reinstall from verified new, wait for rebuild).

Next suggestion was to misinterpret my mail and recommend that I repeat the steps I had just performed.

Next suggestion was to start fresh with a toy program (funny, how all these suggestions involve me spending my time) in a freshly installed Eclipse and plugin. Did that, also tested the toy program in the bug-exhibiting Eclipse+plugin (because why wait for the obvious next step — it’s no surprise that a trivial program works in a clean environment).

If I didn’t know better, I’d say we had a developer in denial. “Can’t be my mistake, that dr2chase guy must just be an uck-fup who can’t do anything right”.

I am reminded, also, of a friend’s “killer app for Python” — when the application crashes in the field, Python emits a very informative stack trace. Their harness captures that stack trace, compresses it, and asks the user to please forward it to the developers, with the usual assurances about confidential info staying confidential. Developer opens informative package that contains all the automatically gathered relevant information, figures out bug, tests and posts a fix, and the next interaction with the customer is to tell them where to get their fix. Developer is productive, customer is happy and thinks that developer is a genius. Oddly enough, that doesn’t seem to be happening here.

Of course, there is a next step, try loading the bug-triggering project into the clean Eclipse, and see if it reoccurs there. 40 minutes later, bug repeats.

And finally, someone who knows how to fix it, looks at it. Yay!

Or not. It’s apparently still broken. But they’re working on it. With much fiddling, the performance of a rebuild has been delightfully improved, whether for success (2.8.0) or failure (2.8.1).

8 Responses to “Scala 2.8.1 IDE bug, Eclipse 3.5 and 3.6.1 (FIXED, SORT OF)”

  1. abyli Says:

    I seem to have exactly the same problem, only on Ubuntu 10. But my problem persists after I updated the scala plugin today. Can you please tell me how your problem was fixed? libo0001@gmail.com

    • dr2chase Says:

      My current workaround is to wait a bit, and tend my garden (it is the weekend, after all). Apparently it should be fixed in the nightly builds, tonight.

      IF you decide to file a bug, be dead sure that you don’t have some sort of a version mismatch. I don’t know if this bug looks like a version problem bug, or if that is just the default scala-ide first answer to all bug reports. An earlier “bug” (some months back) was caused by version screwup in our build, which has since been well and truly flushed.

  2. dlucek Says:

    I am having the same problem with and with out the Scala plugin, but I am using a Scala based jar in my Java application. This issue happens in both 3.5.2 and in Helios 3.6 SR1 (with both the Scala plugin installed and not installed).

    Is there any work around for this?


  3. fullung Says:

    This happens for with normal Helios SR1 (no Scala plugin or anything) when I try to use the Java parts of the Akka library from my Java code.

    My classpath contains:

  4. donnchadh Says:

    I’m also seeing this in Helios 3.6 SR1. There is a bug logged against eclipse 3.7 https://bugs.eclipse.org/bugs/show_bug.cgi?id=332423 . It looks like the the scala compiler is incorrectly creating the class file.
    This looks slightly related:
    but I haven’t found a bug report for the compiler problem causing this.

    • dr2chase Says:

      I went looking at that bug, and the steps to reproduce some of the outputs were utterly lacking. People need to say, explicitly, what should be on paths, and what options should be passed to what commands, and to specify fully package-qualified class names.

      I did this (will this work, as a comment?)

      javap -classpath "/Users/dr2chase/Downloads/2010-03/eclipse/configuration/org.eclipse.osgi/bundles/201/1/.cp/lib/scala-library.jar:bin" -s -c -verbose scala.collection.immutable.Nil

      piped into a file, then went looking in the file for “orElse” and found it in the constant pool at line 310 (has angle brackets, I fear to cut/paste).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: