GroovyEclipse and the ClassLoader Conundrum
Note that this document is likely to contain inaccuracies at this time - in its current form it should be thought of as a brain storm. This ClassLoader business has been known to explode heads, and so learning about it progresses at a slow and careful pace.
The Problem
A problem with implementing GroovyEclipse in Groovy is that development is tied to a single version of Groovy. If compilation is allowed with another version of Groovy, duplicate classes will occur which leads down the path of pain.
Example:
groovy-1.0.jar groovy-1.0-all.jar GroovyEclipse /----------> SomeClass AST Some Analysis---------/
Now the analysis which uses a ClassNode class loaded from groovy-1.0.jar is trying to analyze some AST which contains a ClassNode loaded from groovy-1.0-all.jar. These are not equal, and so the JVM will make that fact known in the most unpleasant way possible.
The Solutions
Do Nothing
GroovyEclipse is locked to the current release of Groovy. This sucks but it is the current state of affairs.
Maintain Multiple GroovyEclipses
Maintain multiple GroovyEclipses locked to the different Groovy versions. The programmer needs to enable different versions of GroovyEclipse and restart the IDE for the change to take place.
This is not very nice if working on different projects that depend on different versions of Groovy.
Create Plugins that Wrap groovy-*.jar
Enable whichever one you need and restart the IDE for the change to take place. The end result is similar to maintaining multiple GroovyEclipse versions.
Hope and pray that the org.codehaus.groovy.ast.* packages don't change
Extract these packages into their own jar. Maintain custom groovy versions that link to this common jar. These groovy versions also contain implementations of the compilation interface, IGroovyCompiler. The programmer can select a version per project/global scope. So:
eclipse-groovy-ast.jar
/ | \
/ | \
/ | \
GroovyEclipse eclipse-groovy-1.0.jar eclipse-groovy-1.1.jar
The eclipse-groovy-*.jars implement IGroovyCompiler extending a compilation extension point.
GroovyEclipse loads these extensions and can use which ever one is necessary. Multiple interfaces may be loaded by a class loader without problems.
This might even work. As long as extracting eclipse-groovy-ast.jar is feasible in the long term. For each version of Groovy, there is a little work to package it up as a GroovyEclipse plugin.
Code the plugin in Java
And drive GroovyEclipse developers to take up fishing ... forever. And there will still be class loader problems, just not as many.
Convince Groovy developers to extract interfaces for AST classes
Yes, that's it. No, probably not. However GroovyEclipse could have such interfaces and implementations that are simply proxies for the AST. This is a lot of work, but probably the most future proof. New features would be extension interfaces. And since this is only for analysis, the proxies would only be created on demand when analysis tools want an AST.
There is still the problem of ASTs containing references to classes in the groovy runtime. And also, how much work is really involved? AST interfaces. AST visitor interfaces, which means a new visitor implementation. What else? And will it never be necessary to dip into the groovy runtime itself?
