GRECLIPSE

Cannot CTRL+click any symbol in a Spock specification (NoClassDefFoundError)

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.0Release
  • Fix Version/s: 2.0.2Release
  • Component/s: None
  • Labels:
    None
  • Environment:
    GREclipse 2.0 RC4
  • Number of attachments :
    0

Description

I cannot CTRL+click any symbol in a Spock specification. Sometimes CTRL+clicking does nothing (symbol doesn't turn into a link when I hover over it), sometimes it opens a pop-up "Go To Declaration | Go To Implementation", but that doesn't really work either.
As soon as I hover over a symbol with CTRL held, the error log is flooded with the following entry:

eclipse.buildId=M20090917-0800
java.version=1.6.0_17
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/xxx/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/xxx/.eclipse_keyring -showlocation

This is a continuation of log file /swd/prj/workspaces/spock-groovy-1.7/.metadata/.bak_1.log
Created Time: 2010-01-09 21:34:50.329

Error
Sat Jan 09 21:39:59 CET 2010
Unhandled event loop exception

java.lang.NoClassDefFoundError: Could not initialize class org.spockframework.compiler.SpockTransform
at sun.reflect.GeneratedConstructorAccessor16.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperationsForGlobalTransforms(ASTTransformationVisitor.java:348)
at org.codehaus.groovy.transform.ASTTransformationVisitor.doAddGlobalTransforms(ASTTransformationVisitor.java:315)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addGlobalTransforms(ASTTransformationVisitor.java:208)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperations(ASTTransformationVisitor.java:171)
at org.codehaus.groovy.control.CompilationUnit.<init>(CompilationUnit.java:207)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.<init>(GroovyParser.java:142)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.<init>(GroovyParser.java:94)
at org.codehaus.jdt.groovy.integration.internal.MultiplexingSourceElementRequestorParser.<init>(MultiplexingSourceElementRequestorParser.java:67)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:295)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1094)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:170)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:430)
at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1213)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.getModuleNode(GroovyCompilationUnit.java:176)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectHelper.select(CodeSelectHelper.java:36)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:525)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:517)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:512)
at org.eclipse.jdt.internal.ui.javaeditor.JavaElementHyperlinkDetector.detectHyperlinks(JavaElementHyperlinkDetector.java:67)
at org.eclipse.ui.texteditor.HyperlinkDetectorRegistry$HyperlinkDetectorDelegate.detectHyperlinks(HyperlinkDetectorRegistry.java:80)
at org.eclipse.jface.text.hyperlink.HyperlinkManager.findHyperlinks(HyperlinkManager.java:263)
at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:439)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:199)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3543)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1250)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1273)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1079)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3441)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3100)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Eisenberg added a comment -

This looks like a problem with AST Transforms. A similar problem was described in GRECLIPSE-605. We released a separate build for this (so as not to disturb the release canadidate, because the fix here will not make it into the final release). Can you try out the release described in that bug and see if it fixes the problem you describe?

Show
Andrew Eisenberg added a comment - This looks like a problem with AST Transforms. A similar problem was described in GRECLIPSE-605 . We released a separate build for this (so as not to disturb the release canadidate, because the fix here will not make it into the final release). Can you try out the release described in that bug and see if it fixes the problem you describe?
Hide
Permalink
Benjamin Gudehus added a comment - - edited

Using greclipse 2.0.0.xx-20100108-1500-e35-special.

I tested this with spock-multiple-specs-suite.zip from GRECLIPSE-609.

import spock.lang.Specification

class FoobarSpec extends Specification {

    Foobar barbar
	
    def "example for foobar"() {
        when:
        def foobar = new Foobar()
        
        then:
        foobar.baz == 42
    }

}

CTRL+click on Foobar on line def foobar = new Foobar() jumps to the method header and selects "example for foobar".

Show
Benjamin Gudehus added a comment - - edited Using greclipse 2.0.0.xx-20100108-1500-e35-special. I tested this with spock-multiple-specs-suite.zip from GRECLIPSE-609 . import spock.lang.Specification class FoobarSpec extends Specification { Foobar barbar def "example for foobar" () { when: def foobar = new Foobar() then: foobar.baz == 42 } } CTRL+click on Foobar on line def foobar = new Foobar() jumps to the method header and selects "example for foobar" .
Hide
Permalink
Andrew Eisenberg added a comment -

Benjamin,

It looks like the e35-special release fixed the initial problem above, but you uncovered a different one. The problem you are seeing comes around because of the source transformations in the code. Because of the source transformations, the AST node that the carat is on can no longer be found.

Initially, I thought that if I could just get my hands on the source code before AST Transforms are applied, then this problem can be solved. However, that's wrong. In this case, it may work, but in general, there is a problem that the code will not resolve until after transformations are applied.

So, this becomes a chicken and egg problem (or is it a Catch-22, I'm never sure). We can't perform code select before transforms are applied since the code cannot resolve, but we cannot perform it after because the source locations are changed.

I'll have to think about this some more, but I wonder if there is a way that AST transforms can be more robust about maintaining source locations.

Show
Andrew Eisenberg added a comment - Benjamin, It looks like the e35-special release fixed the initial problem above, but you uncovered a different one. The problem you are seeing comes around because of the source transformations in the code. Because of the source transformations, the AST node that the carat is on can no longer be found. Initially, I thought that if I could just get my hands on the source code before AST Transforms are applied, then this problem can be solved. However, that's wrong. In this case, it may work, but in general, there is a problem that the code will not resolve until after transformations are applied. So, this becomes a chicken and egg problem (or is it a Catch-22, I'm never sure). We can't perform code select before transforms are applied since the code cannot resolve, but we cannot perform it after because the source locations are changed. I'll have to think about this some more, but I wonder if there is a way that AST transforms can be more robust about maintaining source locations.
Hide
Permalink
Peter Niederwieser added a comment -

Transforms should be written in such a way that they keep source locations intact. Spock certainly tries to do this, and it seems to work out fine in stack traces.
Anyway, I think it would already be a big step forward to resolve symbols before AST transform have run. Many transforms (like Spock's) don't introduce any new declarations called from user code. And even if they do, the majority of the code will still be resolved correctly.

Show
Peter Niederwieser added a comment - Transforms should be written in such a way that they keep source locations intact. Spock certainly tries to do this, and it seems to work out fine in stack traces. Anyway, I think it would already be a big step forward to resolve symbols before AST transform have run. Many transforms (like Spock's) don't introduce any new declarations called from user code. And even if they do, the majority of the code will still be resolved correctly.
Hide
Permalink
Andrew Eisenberg added a comment -

I'm taking a look at the AST of the spock class in comment 2. It seems that the body of the "example for foobar"() method has been moved to the $spock_feature_0_0 method, which does appear to be a new declaration introduced by Spock.

Although, I do agree that there is probably no way we can support the general case of AST transforms that do major havoc on the original AST, we need to have a good strategy for handling the simpler cases.

The problem is that creating a resolved AST takes time and in some situations (like reconciling and content assist), we need to have the AST transforms applied before we can do the work. But in other situations (like code select and navigation), we need to use the untransformed AST. And in some cases, we may need both. Groovy-Eclipse tries to be as smart as possible and caches ASTs when they are created.

Getting this working correctly may turn out to be as simple as caching the untransformted AST instead of the transformed AST, but it may also turn out to be horribly complicated.

Show
Andrew Eisenberg added a comment - I'm taking a look at the AST of the spock class in comment 2. It seems that the body of the "example for foobar"() method has been moved to the $spock_feature_0_0 method, which does appear to be a new declaration introduced by Spock. Although, I do agree that there is probably no way we can support the general case of AST transforms that do major havoc on the original AST, we need to have a good strategy for handling the simpler cases. The problem is that creating a resolved AST takes time and in some situations (like reconciling and content assist), we need to have the AST transforms applied before we can do the work. But in other situations (like code select and navigation), we need to use the untransformed AST. And in some cases, we may need both. Groovy-Eclipse tries to be as smart as possible and caches ASTs when they are created. Getting this working correctly may turn out to be as simple as caching the untransformted AST instead of the transformed AST, but it may also turn out to be horribly complicated.
Hide
Permalink
Peter Niederwieser added a comment -

What I tried to convey is that Spock's transform doesn't add any declaration which are referred to from the original source code. I can't see why the IDE would care about $spock_feature_0_0, but of course I don't know the details.
IMHO it's not so important for an IDE to understand all possible consequences of running an (evil) transform. It's more important to handle the general case well (transforms that don't change the user-visible part of a class).

Show
Peter Niederwieser added a comment - What I tried to convey is that Spock's transform doesn't add any declaration which are referred to from the original source code. I can't see why the IDE would care about $spock_feature_0_0, but of course I don't know the details. IMHO it's not so important for an IDE to understand all possible consequences of running an (evil) transform. It's more important to handle the general case well (transforms that don't change the user-visible part of a class).
Hide
Permalink
Andrew Eisenberg added a comment -

I have raised GRECLIPSE-617 that describes a few potential solutions.

The reason why we care about $spock_feature_0_0 is because of the reconcile operation. Reconcile is like a mini-compile that occurs as you type that ensures that the internal model is always up to date with the latest workspace state. The result of a reconcile feeds into all sorts of other operations (just about every operation that requires an AST). For a while, AST Transforms were disabled for reconcile, but this caused all sorts of problems to happen (eg- Test annotations not being added to spock tests during a reconcile and therefore spock tests not looking like JUnit tests at all). And the fact that other operations use the transformed AST is an artifact of that is what is available after a reconcile.

Show
Andrew Eisenberg added a comment - I have raised GRECLIPSE-617 that describes a few potential solutions. The reason why we care about $spock_feature_0_0 is because of the reconcile operation. Reconcile is like a mini-compile that occurs as you type that ensures that the internal model is always up to date with the latest workspace state. The result of a reconcile feeds into all sorts of other operations (just about every operation that requires an AST). For a while, AST Transforms were disabled for reconcile, but this caused all sorts of problems to happen (eg- Test annotations not being added to spock tests during a reconcile and therefore spock tests not looking like JUnit tests at all). And the fact that other operations use the transformed AST is an artifact of that is what is available after a reconcile.
Hide
Permalink
Benjamin Gudehus added a comment - - edited

I've got some questions related to ctrl+click jumps within ast-tranformated code.

First, I don't know if there is a difference between these cases:

1. Jumping to symbols defined in another file (e.g. class definition, method definitions).
2. Jumping to symbols defined in the same class (e.g. class attributes, non-ast transformed class methods)
3. Jumping to symbols defined in another ast-transformated block (e.g. given:, when:, then:, ...)

Will all of these cases work as soon as the ast-transformated method is parsed properly (i.e. there is no difference between these cases and no need to deal in different ways with them)?

Further, the ast-tranformed methods are the feature methods (feature methods as defined here: http://code.google.com/p/spock/wiki/SpockBasics) and these are the only methods, where I can't jump to the symbols. In all of the three cases the ctrl+click jumps don't work.

So, why can't we even jump to symbols defined outside of the ast-transformated methods (cases 1 and 2)? Does Groovy-Eclipse need to identify the symbols in the ast-transformed block to jump to it's definitions?

--Benjamin

Show
Benjamin Gudehus added a comment - - edited I've got some questions related to ctrl+click jumps within ast-tranformated code. First, I don't know if there is a difference between these cases: 1. Jumping to symbols defined in another file (e.g. class definition, method definitions). 2. Jumping to symbols defined in the same class (e.g. class attributes, non-ast transformed class methods) 3. Jumping to symbols defined in another ast-transformated block (e.g. given:, when:, then:, ...) Will all of these cases work as soon as the ast-transformated method is parsed properly (i.e. there is no difference between these cases and no need to deal in different ways with them)? Further, the ast-tranformed methods are the feature methods (feature methods as defined here: http://code.google.com/p/spock/wiki/SpockBasics ) and these are the only methods, where I can't jump to the symbols. In all of the three cases the ctrl+click jumps don't work. So, why can't we even jump to symbols defined outside of the ast-transformated methods (cases 1 and 2)? Does Groovy-Eclipse need to identify the symbols in the ast-transformed block to jump to it's definitions? --Benjamin
Hide
Permalink
Andrew Eisenberg added a comment -

The problem is not where you are going to, but rather where you are coming from. If the carat is currently inside of a transformed code block, then navigation will not work, no matter where the declaration actually exists.

There are two steps to navigation (or code select is the more proper name):

  1. Figure out what AST node is currently being selected.
  2. Figure out what declaration this AST node resolves to.

It is the first part where we fail since the code visitor cannot find the selected node to resolve.

So, to answer your first question: Yes. And the second question: Yes.

Show
Andrew Eisenberg added a comment - The problem is not where you are going to, but rather where you are coming from. If the carat is currently inside of a transformed code block, then navigation will not work, no matter where the declaration actually exists. There are two steps to navigation (or code select is the more proper name): Figure out what AST node is currently being selected. Figure out what declaration this AST node resolves to. It is the first part where we fail since the code visitor cannot find the selected node to resolve. So, to answer your first question: Yes. And the second question: Yes.
Hide
Permalink
Andrew Eisenberg added a comment -

As described in GRECLIPSE-617, this issue is now fixed. Any new problems that you see in this area, please raise in a new issue.

Show
Andrew Eisenberg added a comment - As described in GRECLIPSE-617 , this issue is now fixed. Any new problems that you see in this area, please raise in a new issue.
Hide
Permalink
Peter Niederwieser added a comment -

Based on our team's feedback from today, this seems to work now.

Show
Peter Niederwieser added a comment - Based on our team's feedback from today, this seems to work now.

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Peter Niederwieser
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: