Start Eclipse, get a coffee, come back: the splash screen is still there. The first time, it feels like an invitation to slow down. By the third time, you start wondering whether the IDE is secretly building another IDE.
At RPACT and RCONIS, our work involves both statistical methods and the software used to put them into practice. Occasionally, that means investigating the development tools themselves. This time, the phase before the application actually started took a good two minutes. Copilot and StatET were the initial suspects. In the end, Copilot was indeed involved, although through a surprising detour.
Measure first, suspect later
The affected environment was Eclipse IDE 2025-12, build 4.38.0.20251204-0849, Java 21.0.12.1, and GitHub Copilot for Eclipse 0.21.0.202608060743 on Windows. StatET 4.12.0 was also installed.
The launch command was unremarkable:
& 'C:\Tools\Eclipse\eclipse.exe' -data 'D:\Work\presentations'The paths shown here are examples. What stood out was that the long pause occurred before the workspace opened. That was hardly enough evidence to blame the presentation files.
The workspace log at .metadata/.log did contain errors, including some from CodeTogether. But an error in a log is, initially, just an error in a log. It does not automatically explain the missing two minutes.
The decisive clues came from several Java thread dumps taken during the wait:
Get-Process eclipse,eclipsec -ErrorAction SilentlyContinue
& 'C:\Program Files\Java\jdk-24\bin\jcmd.exe' 12345 Thread.printHere, 12345 is the process ID identified in the previous step; adjust the path to jcmd.exe to match your local JDK installation. If several instances are running, jcmd 12345 VM.system_properties can help identify the workspace through osgi.instance.area. One detail matters on Windows: in this setup, the JVM runs inside eclipse.exe, rather than a separate javaw.exe process.
The main thread was waiting in ConfigApplier.refreshPackages() for a full plugin refresh. Another thread was working in the Equinox/Felix resolver, including PackageSpaces.checkPackageSpaceConsistency().
In plain English: Eclipse was searching for a consistent combination of plugin dependencies. And searching. And searching.
The small trigger
A resolver trace showed thousands of rejected combinations involving Bnd/PDE, Servlet, and logging libraries. That explained the work being done, but not why the search had to happen again at every startup.
For that second question, targeted configurator logging was more useful. It can be enabled for a single launch with a JVM option:
& 'C:\Tools\Eclipse\eclipsec.exe' `
-data 'D:\Work\presentations' -consoleLog `
-vmargs -Dequinox.simpleconfigurator.debug=trueThe revealing line, shortened here to its essential part, was:
uninstalled Bundle:com.microsoft.copilot.eclipse.ui.terminal(...)Copilot had installed this additional terminal module at runtime. It was packaged as an embedded JAR inside the Copilot UI plugin and was not listed in the regular bundles.info file.
By default, the Simple Configurator uses exclusiveInstallation=true: additional bundles outside the configured list are removed. In this installation, the resulting refresh triggered a full dependency resolution. Copilot then loaded its terminal module again later. At the next startup, Eclipse removed it again.
A remarkably diligent housekeeping service, carrying the same chair out of the room every morning.
The configurator’s behavior can be traced in the official Equinox source code. The ConfigApplier implementation also shows why changes during startup can trigger a full refresh.
The workaround: leave the chair where it is
The tested workaround was a single additional line in eclipse.ini, below the existing -vmargs line:
-Dorg.eclipse.equinox.simpleconfigurator.exclusiveInstallation=falseI backed up the file before changing it. This option prevents the blanket removal of additionally installed bundles. In this installation, it allowed the Copilot terminal module to remain installed, avoiding the expensive refresh. Neither Copilot nor StatET had to be uninstalled.
| Measurement | Time until “Starting application” |
|---|---|
| Without the workaround | 125.8 seconds |
| With the workaround, first test | 3.9 seconds |
| With the workaround, repeat test | 3.5 seconds |
That is approximately 97 percent less waiting during this startup phase. Restoring editors and running further background tasks still happen afterwards. After making the change permanent, I also successfully checked the original launch command without any additional parameters.
The option applies to future launches of the same Eclipse installation. Instances that are already running pick it up only after a restart. To undo the change, remove the added line.
Pitfalls worth remembering
A fresh test workspace does not isolate the entire installation. Even a separate -configuration can still use shared p2 metadata. During diagnosis, one of my test launches changed the shared installation profile in exactly this way. The newly generated profile states were backed up separately, and the previous state was restored. A fast startup was confirmed again afterwards. For experiments like these, a fully separate copy of the installation is the better choice.
Access denied does not automatically mean diagnosis is impossible. In the sandbox used for this investigation, Java attach access initially failed; outside that restriction, it worked. This was not evidence that Eclipse itself needed administrator privileges.
-clean is not a useful permanent companion. It discards caches that normally save work. The Eclipse documentation explains its effect.
The workaround has a specific purpose and limits. It changes how the configurator handles additional bundles; it is not a universal startup accelerator. After plugin updates, revisit the diagnosis and test whether the option is still needed. This investigation did not check a later update for a vendor fix.
The most useful result was therefore more than a single configuration line: the thread dumps showed where the time went, and the targeted log explained why. StatET got to stay. And now the coffee can wait until after startup again.
If you use Eclipse and StatET for R development, you may also find our earlier post on troubleshooting StatET RMI registry port errors on Windows useful.