#1001202
  • Created on
    2012-08-09 08:33
  • Reported by
    greenrd
  • Status
    Fixed
  • Priority
    Normal (3)
  • Assigned to
    Mirco Dotta
  • Milestone
    Helium M3
  • Plan Level
    -
  • Permission type
    Public
  • Due Date
    -

Attachments

Related Tickets

Add new subtask or bug

Unable to set breakpoint in source attachment opened via .class file in dependency

I have a project with a transitive dependency on recursivity-commons_2.9.1-0.6.jar. I used the sbt-eclipse plugin to download source and javadoc attachments for dependencies. In order to set a breakpoint, I opened

my project -> Referenced Libraries -> recursivity-commons_2.9.1-0.6.jar -> com.recursivity.commons.bean -> GenericTypeDefinition.class

This correctly opened the corresponding .scala source file. I then attempted to set a breakpoint on this line:

case class GenericTypeDefinition(clazz: String, genericTypes: Option[List[GenericTypeDefinition]]){


which failed with this exception:


java.lang.UnsupportedOperationException
	at scala.tools.eclipse.javaelements.CompilationUnitAdapter.getPackageDeclarations(CompilationUnitAdapter.scala:164)
	at org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter.createQualifiedTypeName(ToggleBreakpointAdapter.java:537)
	at org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter.getQualifiedName(ToggleBreakpointAdapter.java:493)
	at org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter$4.run(ToggleBreakpointAdapter.java:423)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
User picture
  on 2012-10-11 10:27 *
By Iulian Dragos
Milestone set to Helium
User picture
  on 2012-10-26 12:20 *
By Iulian Dragos
Milestone changed from Helium to Helium M3
Updating tickets (#1000864, #1001000, #1001001, #1001197, #1001202, #1001211, #1001225, #1001241, #1001267, #1001288, #1001289, #1001290)
User picture
  on 2012-10-29 10:24 *
By Iulian Dragos
Assigned to set to login
Milestone changed from Current to Helium M3
User picture
  on 2012-12-04 09:43 *
By Mirco Dotta
Milestone changed from Helium M3 to Current
User picture
  on 2012-12-04 09:49 *
By Mirco Dotta
Assigned to set to Mirco Dotta
User picture
  on 2012-12-04 10:33 *
By Mirco Dotta
Status changed from New to Accepted
User picture
  on 2012-12-04 10:33 *
By Mirco Dotta
I can reproduce this. Now digging.
User picture
  on 2012-12-06 10:23 *
By Mirco Dotta
Status changed from Accepted to Fixed
(In scala-ide:e7b57e7fecf9f1c7ccf2a61cbb47a1dc25820d55) Merge pull request #246 from dotta/issue/unable-to-set-breakpoint-1001202

Fix #1001202 - Unable to set breakpoint in source attachment

Branch: master
User picture
  on 2012-12-06 10:23 *
By Mirco Dotta
(In scala-ide:687e52b7463489c156636ad721e3abaea2368401) Fix #1001202 - Unable to set breakpoint in source attachment

It turns out that setting a breakpoint on a module declaration could sometime
fail badly (an error dialog was displayed to the user).

The reason why this fails is really simple, a call to
``CompilationUnitAdapter.getPackageDeclarations`` is performed while trying to
toggle the line breakpoint in the editor. And, because the existing
implementation of ``CompilationUnitAdapter.getPackageDeclarations`` used to
throw an ``UnsupportedOperationException``, it's not a surpise that this used
to fail badly.

The quick fix was to implement that method so that the ``PackageDeclaration``
for the opened classfile source is returned. And, in the specific case, the
``PackageDeclaration`` is only needed to find the raw package name, which is
why I have only implemented the ``getElementName`` (look at
``ToggleBreakpointAdapter.createQualifiedTypeName``, at some point you will see
a call to ``pd[0].getElementName();``, where ``pd`` is the
``PackageDeclaration``). This seems to be enough for fixing this specific
issue, and all considered, this fix can only improve on the status quo (simply
because the former implementation thrown an exception right away).

This PR doesn't come with test because the functionality is in the editor, and
we currently don't have a way to create UI tests.

That said, the whole logic we use to handle classfile sources looks a bit
broken. First, why do we need ``ScalaClassFile`` to extend
``ScalaCompilationUnit``? That does not quite make sense to me. And the fact
that the JDT ``ClassFile`` does not extend the JDT ``ICompilationUnit`` just
give one more indication that this is likely not needed. And, if we could make
``ScalaClassFile`` not to extends ``ScalaCompilationUnit``, we could then get
rid of the ``CompilationUnitAdapter``. I've been spending a bit of time looking
into this, but unfortunately I don't have time to experiment this any further
at the moment. I've pushed what I have
[here](https://github.com/dotta/scala-ide/tree/wip/classfile-not-a-compilation-unit),
it's not clean but it should give an idea of where I am heading with this (and
hopefully I'll work on this during my spare time some time in the future).

Branch: master
User picture
  on 2012-12-14 13:20 *
By Mirco Dotta
Fixed in version set to 2.1.0-m3
User picture
  on 2012-12-14 13:47 *
By Mirco Dotta
Milestone changed from Current to Helium M3