Detect plugins lazily when loading a site from disk - #2862
Merged
Conversation
PlatformConfiguration.reconcile() calls SiteEntry.loadFromDisk(), which eagerly scanned the plugins directory and opened every jar on the site to read its manifest. On the IDE startup path this runs synchronously on the UI thread: WorkbenchActionBuilder asks for bundle groups to decide whether to contribute the Welcome and Tips and Tricks actions, which builds the PlatformConfiguration and triggers the scan. Only feature entries are ever consulted on that path, so the jar scan is wasted work and cost seconds on installations with many plugins. Drop the eager detectPlugins() call. Every consumer of the plugin data already null-checks pluginEntries and detects on demand, and the persistence path (SiteEntry.toXML) writes only site attributes and feature entries, so nothing is lost from platform.xml. The change stamp bookkeeping is untouched, and a deferred scan sees pluginEntries == null exactly as the eager one did, so it still performs a full scan rather than a timestamp comparison.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves Eclipse IDE startup responsiveness by deferring expensive plugin-jar scanning when a SiteEntry is loaded from disk. It removes an eager plugin detection step from SiteEntry.loadFromDisk() (which can run synchronously on the UI thread during startup) and relies on the existing lazy, null-checked plugin detection pathways.
Changes:
- Stop eagerly scanning the
plugins/directory (and opening every jar) duringSiteEntry.loadFromDisk(). - Add JUnit tests to verify features are detected without pre-populating plugin entries, and that plugins are still detected on first access.
- Wire the new test into the existing automated configurator test suite and add the required JUnit package import.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| update/org.eclipse.update.configurator/src/org/eclipse/update/internal/configurator/SiteEntry.java | Removes eager detectPlugins() call during disk load to defer jar scanning until plugin data is requested. |
| update/org.eclipse.update.configurator.tests/src/org/eclipse/update/internal/configurator/tests/SiteEntryTests.java | Adds coverage asserting lazy plugin detection behavior and feature detection without eager plugin population. |
| update/org.eclipse.update.configurator.tests/src/org/eclipse/update/configurator/tests/AutomatedConfiguratorSuite.java | Registers the new test class in the existing JUnit Platform suite. |
| update/org.eclipse.update.configurator.tests/META-INF/MANIFEST.MF | Imports org.junit.jupiter.api.io for @TempDir usage in the new tests. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SiteEntry.loadFromDisk()eagerly scanned the plugins directory and opened every jar on the site to read its manifest. That happens on the IDE startup path, synchronously on the UI thread:WorkbenchActionBuilderasks for bundle groups to decide whether to contribute the Welcome and Tips and Tricks actions, which builds thePlatformConfigurationand triggers the scan. On a user-reported freeze this burned about 5.5 seconds.The scan is wasted work there. That path only ever reads feature entries, and every consumer of the plugin data already null-checks
pluginEntriesand detects on demand, so dropping the eagerdetectPlugins()call simply defers the cost to whoever actually needs it. The change-stamp bookkeeping is untouched, and a deferred scan still seespluginEntries == nulland performs the same full scan the eager one did. Persistence is unaffected:SiteEntry.toXMLwrites only site attributes and feature entries, so nothing is lost fromplatform.xml.Adds
SiteEntryTests, which asserts that features are detected without opening any plugin jar and that plugins are still found on first access.