Repository navigation
JavaSourceUiDescriber scans the entire document to detect GUI files; should be bounded #1641
Description
Body:
WindowBuilder registers a by-contents content describer (JavaSourceUiDescriber)
that reads the whole file to look for GUI markers. Most describers inspect only
a prefix; this one makes EVERY content-type query on a large file O(file size).
(Stack: see LSP4E issue 3a — org.eclipse.wb.internal.core.editor.describer.
JavaSourceUiDescriber.describe called via ContentTypeCatalog.describe on every
LSP4E query.)
Expected: bound the scan (e.g. first N KB) or use a cheap heuristic first.
Activity
ptziegler commentedon Sep 25, 2026
I don't think there really is a "cheap" heuristic to determine, whether a file contains UI components. But I believe there are a couple of things that could be made more efficient.
When all WindowBuilder plugins are installed, the complexity of the algorithm is O(6n), with n being the length of the document. Once, because the entire document is copied to a string and once for each pattern. With e.g. the Aho-Corasick algorithm, this can be reduced to O(n+m), with m being the length of the longest pattern.
As an additional step, one could also only look at the import statements. So we only look until we find the type definition. E.g. the first occurrence of
class,recordorenum. Or perhaps even just{. There's still be an issue if all UI classes are referenced by their fully-qualified name instead of being imported, but I highly doubt that's the common use case.Simplify detection logic in JavaSourceUiDescriber eclipse-windowbuild…
Simplify detection logic in JavaSourceUiDescriber #1641
vogella commentedon Sep 30, 2026
Patterns could also be cached, see #1653