#1001925
  • Created on
    2013-10-17 07:11
  • Reported by
    Mirco Dotta
  • Status
    Fixed
  • Priority
    Normal (3)
  • Assigned to
    Mirco Dotta
  • Milestone
    Lithium M1
  • Plan Level
    -
  • Permission type
    Public
  • Due Date
    -

Attachments

Related Tickets

Add new subtask or bug

ClassCastException when opening classfile with no associated source

When opening a classfile that has no associated source, an error dialog is prompted, and the following exception is logged:
java.lang.ClassCastException: org.eclipse.jdt.internal.core.ClassFile cannot be cast to scala.tools.eclipse.InteractiveCompilationUnit
	at scala.tools.eclipse.ScalaCompilationUnitEditor$class.getInteractiveCompilationUnit(ScalaCompilationUnitEditor.scala:94)
	at scala.tools.eclipse.ScalaClassFileEditor.getInteractiveCompilationUnit(ScalaClassFileEditor.scala:20)
	at scala.tools.eclipse.semantichighlighting.Presenter$SemanticHighlightingJob.performSemanticHighlighting(Presenter.scala:117)
	at scala.tools.eclipse.semantichighlighting.Presenter$SemanticHighlightingJob.run(Presenter.scala:113)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


Most likely, this commit is to blame for the problem.
User picture
  on 2013-10-17 07:12 *
By Mirco Dotta
Status changed from New to Accepted
This likely happens with 3.0.2-RC2 and, if it does, it's a regression wrt 3.0.1. So, even though it's not a big issue, I wonder if this should block 3.0.2 final. I'm going to work on fixing this right away.
User picture
  on 2013-10-17 08:10 *
By Mirco Dotta
Description changed from When opening a classfile th... to When opening a classfile th...
User picture
  on 2013-10-17 08:19 *
By Iulian Dragos
It should be an easy fix. It's unfortunate, but we have to fix it and go for RC3.
User picture
  on 2013-10-17 08:52 *
By Mirco Dotta
Actually, this is less serious than I thought, as I seem to be able to reproduce the exception only if I open a classfile via the Open Resource dialog (simply opening a classfile for which there are no source attachments doesn't lead to the above reported exception).
User picture
  on 2013-10-18 15:03 *
By Mirco Dotta
Status changed from Accepted to Fixed

In scala-ide:67c6cfeefaae2fe66cbd6f3be206e6c56ce40e0b `ScalaClassFileEditor` should always hold a `ScalaClassFile`

There doesn't seem to be a good reason for not creating a `ScalaClassFile` when
source attachments cannot be located.

Doing so has two nice consequences:

1) When sources are manually attached to a Scala JAR, and a classfile is opened
in an editor, the source is now correctly syntactically highlighted. This
basically fix half of ticket Re #1001926 (the other half is triggering
semantic highlighting).

2) `ScalaClassFileEditor` instances are now ensured to be always created with
an underlying `ScalaClassFile`. This is an important fact, as
`ScalaClassFileEditor` assumes it (in fact, the `ClassCastException`
reported in ticket Re #1001925 was happening because this implicit contract
was broken, i.e., it was possible that a `ScalaClassFileEditor` could be
created with a (Java) `ClassFile` when no source attachment was found.

By the way, the `ClassCastException` issue mentioned in point 2) could be
reproduced by copying a **Scala** classfile in the root of a project, and then
trying to opening (by double-clicking on it from the Package Explorer view)
would result in an error prompted to the user.

Fixes #1001925

Committed to: scala-ide