AnalyticsPingManager makes eclipse unresponsive

We have our projects configured with gradle. Just to clarify, we also added the gwtNature to our Gwt projects, at least we tried. However, when doing so, Eclipse becomes unresponsive. This means that using intellisense freezes the workspace by 30 seconds or more. We observed a lot of log spam in the Eclipse log files:

```
ENTRY com.gwtplugins.gwt.eclipse.core 4 0 2016-12-07 16:42:11.937
!MESSAGE Cannot get version of GWT SDK "C:\workspaces\devtools\gradleHome\caches\modules-2\files-2.1\com.google.gwt\gwt-servlet\2.8.0\8fba7d39f9a341892cda502aacb2f5287bd49309", ensure it is configured properly
!STACK 0
java.lang.ClassNotFoundException: com.google.gwt.dev.About
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.google.gwt.eclipse.core.runtime.GwtSdk.getVersion(GwtSdk.java:467)
at com.google.gdt.eclipse.core.sdk.SdkUtils$MaxSdkVersionComputer.computeMaxSdkVersion(SdkUtils.java:46)
at com.google.gdt.eclipse.suite.update.usage.AnalyticsPingManager.getSdkVersions(AnalyticsPingManager.java:112)
at com.google.gdt.eclipse.suite.update.usage.AnalyticsPingManager.sendPing(AnalyticsPingManager.java:103)
at com.google.gdt.eclipse.suite.update.usage.AnalyticsPingManager.sendCompilationPing(AnalyticsPingManager.java:75)
at com.google.gdt.eclipse.suite.update.builders.UpdateTriggerCompilationParticipant.isActive(UpdateTriggerCompilationParticipant.java:37)
at org.eclipse.jdt.internal.core.JavaModelManager$CompilationParticipants.getCompilationParticipants(JavaModelManager.java:440)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java:589)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:169)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
```

First, could you add some more log information on which projects that happend?
Second, do we really need to recalculate everything, everytime? Can't there be some caching, or

We didn't have those problem with the old plugin. The workaround for now was simply not to add the gwt nature to the projects (or unticking 'Use Gwt'), resulting in not really using the GWT plugin.

Could it be that projects which are not using GWT, but have gwt-servlet on the classpath might cause some problems?

Start with AnalyticsPingManager.java, especially sendPing and getSdkVersions, then trace the calls through UpdateTriggerCompilationParticipant.java and GwtSdk.java using the stack trace. Determine how project context and repeated SDK-version calculation contribute to the reported log spam and freezes. Done should include more useful project-specific logging and a verified reduction or avoidance of unnecessary recalculation.

Escrito por el modelo de indexación a partir del texto del issue.