Unable to switch groovy compiler version. Error in the UI (red elements)

[marioja]

I installed greclipse in eclipse 2019-09 from https://dist.springsource.org/snapshot/GRECLIPSE/e4.13. When I look at the groovy compiler preferences it is using 3.0.0-rc-1. If I click the switch to 2.5.8.v201910292244-e1909 then when eclipse restarts I get errors in the user interface: (red circles with X in them and messages such as: Failed to create the part's controls in Enterprise Explorer and invalid registry object in a text editor window).

If I switch back to version 3.0.0-rc-1 then everything gets back to normal. The net effect is that I cannot switch version.
I have attached the .log in the .metadata workspace folder
.log

[eric-milles]

This has been discussed at length in #317. If you close all your editors and disable auto build, the compiler switcher may work better. Otherwise the workaround available is to uninstall any compiler versions newer than the one you want to use. This is a timing-based issue, so it is hard to make much progress on it without a high effort investment.

[marioja]

I read some stuff in issue #317. Is the issue in eclipse, M2E or the groovy plugin? I know timing issues are a pain to fix but I get this error all the time without any editor opened.

[marioja]

Also, if the quick work-around is to remove the newer version, could there not be a UI thing that does this or better yet, why cannot it be removed automatically. This leaves a really sour experience to the unaware user. It took me a few try to understand that the switch was causing the issue. This is intended as a constructive not bashing comment.

[eric-milles]

Sorry that #317 and the linked issues are not light reading. I can sum up and say that the compiler switcher feature is desirable for those that use different Groovy versions between different projects or want to try out pre-releases like Groovy 3. The switcher uses some OSGi "tricks" to unload the unused Groovy compiler/runtime bundles just after the IWorkspace class is loaded. Before Eclipse Neon, this was quite stable. Starting with Eclipse Neon something changed in the platform -- I suspect that some JDT components were migrated to the e4 way of doing things and this resulted in earlier loading.

I am reluctant to remove the switching feature because it does work in some cases -- sorry I can't be more specific about when it works for sure and when it breaks down. I am also reluctant to add a warning message to the feature. There are other known issues in the tooling and my opinion is that an issue ticket here is the proper course of action.

I do sympathize that this issue can become quite a blocker to using Groovy and Java as well. I have done some investigation and made some changes to try and reduce the number of bundles that get reloaded. What needs to happen next is some investigation to understand what GDT/JDT components are loading before the IWorkspace class (or if the IWorkspace trigger is failing). You can help in this area by enabling "-debug" on the command line of eclipse and turning on various tracing flags in Window > Preferences > General > Tracing.

[eric-milles]

Here is an example of the "-debug" output that includes the Groovy compiler switcher:

Start VM:
--add-modules=ALL-SYSTEM
-Dosgi.requiredJavaVersion=1.8
-Dosgi.dataAreaRequiresExplicitInit=true
-Xms1g
-Xmx3g
-Declipse.refreshBundles=true
-Dosgi.clean=true
-Djava.class.path=C:\Users\Public\Eclipse-1909\plugins/org.eclipse.equinox.launcher_1.5.500.v20190715-1310.jar
-os win32
-ws win32
-arch x86_64
-showsplash
-launcher C:\Users\Public\Eclipse-1909\eclipse.exe
-name Eclipse
--launcher.library C:\Users\Public\Eclipse-1909\plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.1100.v20190
907-0426\eclipse_1902.dll
-startup C:\Users\Public\Eclipse-1909\plugins/org.eclipse.equinox.launcher_1.5.500.v20190715-1310.jar
--launcher.appendVmargs
-Declipse.refreshBundles=true
-Dosgi.clean=true
-launcher C:\Users\Public\Eclipse-1909\eclipse.exe
-clean
-console
-debug
-vm C:/Program Files/Java/jdk/13.0.1/bin/server/jvm.dll
-vmargs
--add-modules=ALL-SYSTEM
-Dosgi.requiredJavaVersion=1.8
-Dosgi.dataAreaRequiresExplicitInit=true
-Xms1g
-Xmx3g
-Declipse.refreshBundles=true
-Dosgi.clean=true
-Djava.class.path=C:\Users\Public\Eclipse-1909\plugins/org.eclipse.equinox.launcher_1.5.500.v20190715-1310.jar
Install location:
    file:/c:/Users/Public/Eclipse-1909/
Configuration file:
    file:/c:/Users/Public/Eclipse-1909/configuration/config.ini loaded
Configuration location:
    file:/c:/Users/Public/Eclipse-1909/configuration/
Framework located:
    file:/c:/Users/Public/Eclipse-1909/plugins/org.eclipse.osgi_3.15.0.v20190830-1434.jar
Loading extension: reference:file:org.eclipse.osgi.compatibility.state_1.1.600.v20190814-1451.jar
        eclipse.properties not found
Framework classpath:
    file:/c:/Users/Public/Eclipse-1909/plugins/org.eclipse.osgi_3.15.0.v20190830-1434.jar
    file:/c:/Users/Public/Eclipse-1909/plugins/
    file:/c:/Users/Public/Eclipse-1909/plugins/org.eclipse.osgi.compatibility.state_1.1.600.v20190814-1451.jar
Splash location:
    c:\Users\Public\Eclipse-1909\plugins\org.eclipse.platform_4.13.0.v20190916-1045\splash.bmp
Debug options:
    file:/C:/Users/Public/Eclipse-1909/.options not found
Time to load bundles: 44
Starting application: 6523
osgi> Invalid Groovy compiler level: null
Must be one of 16, 1.6, 17, 1.7, 18, 1.8, 19, 1.9, 20, 2.0, 21, 2.1, 22, 2.2, 23, 2.3, 24, 2.4, 25, 2.5, 26, 2.6, 30 or
3.0
Invalid Groovy compiler level: null
Must be one of 16, 1.6, 17, 1.7, 18, 1.8, 19, 1.9, 20, 2.0, 21, 2.1, 22, 2.2, 23, 2.3, 24, 2.4, 25, 2.5, 26, 2.6, 30 or
3.0
Starting Groovy-Eclipse compiler resolver. Specified compiler level: 2.4
 95 org.codehaus.groovy_2.5.8.201910301206 STARTING
 96 org.codehaus.groovy_2.4.17.201910301412 STARTING
Stopped bundle version 2.5.8.201910301206
Skipped bundle version 2.4.17.201910301412
Refresh bundles:
106 org.codehaus.groovy.eclipse.refactoring_3.6.0.201910301412 STARTING
 99 org.codehaus.groovy.eclipse.astviews_3.6.0.201910301412 STARTING
104 org.codehaus.groovy.eclipse.dsl_3.6.0.201910301412 STARTING
107 org.codehaus.groovy.eclipse.ui_3.6.0.201910301412 STARTING
250 org.eclipse.jdt.groovy.core_3.6.0.201910301412 STARTING
101 org.codehaus.groovy.eclipse.codebrowsing_3.6.0.201910301412 STARTING
103 org.codehaus.groovy.eclipse.core_3.6.0.201910301412 STARTING
 95 org.codehaus.groovy_2.5.8.201910301206 UNINSTALLED
105 org.codehaus.groovy.eclipse.quickfix_3.6.0.201910301412 STARTING
100 org.codehaus.groovy.eclipse.codeassist_3.6.0.201910301412 STARTING
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Application started in : 12001ms

At the end you can see "Starting Groovy-Eclipse compiler resolver." This is followed by a list of the bundles it is choosing from and finally a list of the bundles that got refreshed (that is, bundles that had a link to the Groovy compiler/runtime bundle).

In this case, since all refreshed bundles were still in the STARTING state, the bundle switch completed successfully and I am able to use the Java and Groovy editors normally.

Update: Even when I leave a Groovy Editor and the Package Explorer open, I am able to restart and have Groovy 2.4 switched on without issue. So there must be something that is not in my JavaEE workspace that is starting a GDT/JDT component earlier.

[eric-milles]

What needs to happen next is some investigation [by someone who can recreate this issue] to understand what GDT/JDT components are loading before the IWorkspace class... You can help in this area by enabling "-debug" on the command line of eclipse and turning on various tracing flags in Window > Preferences > General > Tracing. [Above] is an example of the "-debug" output that includes the Groovy compiler switcher.

[eric-milles]

I am approaching a fix from 3 angles:

1. IAdapterFactory instances are registered programatically to avoid creating AdapterFactoryProxy instances. Thus, when Groovy bundles are refreshed/uninstalled, no invalid registry entries are left behind for adapter factories. This seems to be the most common case for error.
2. AdapterFactoryProxy could be fixed to check the isValid() condition on its IContributionElement. And it has been recommended that any use of IContributionElement also check isValid() first.
3. The bundle ch.qos.logback.classic makes optional imports to Groovy packages. This plug-in is used underneath m2e and sl4fj. So a refresh of the Groovy bundles affects a large dependency graph. If I can stop the optional connection between org.codehaus.groovy and ch.qos.logback.classic, the compiler switcher package refresh will be much less impactful.

[eric-milles]

If you remove the "m2e - slf4j over logback logging" feature, you can reduce the impact of compiler switching. This relates to item (3) in the above comment.