The configuration index was invalidated by every Java element event,
including POST_RECONCILE, and its working-copy fingerprint covered every
open editor. Opening the navigation target, closing a tab, or saving
application.yml was enough to make the next Find Usages or YAML key
navigation rebuild the whole project index.
Invalidation now follows what the index depends on:
- POST_CHANGE deltas only, ignoring working-copy open/close, AST-only
flags and non-Java resource content on projects, roots and packages
(configuration files are parsed by the client, metadata files are
stamp-checked).
- The fingerprint covers working copies with unsaved changes only.
Each snapshot reports a generation so the real-server harness can assert
that opening/closing editors, a full build and a saved edit keep it warm,
while a source added on disk still invalidates it.
Bundle 1.2.1 (installed as java-usages-1.2.1.jar so OSGi does not reuse
the cached 1.2.0), reproducible SHA-256
cbae3e3a0bcf2818b4cc9d98998bd9b81f92e1ae7803dc757134485f9776a4e1.
Go to Definition in a Java file asked the configuration command first
whenever the file mentioned "Value" or "getProperty", which in Spring code
is nearly every file. The command builds a project-wide index before it
answers, the index is invalidated by any reconcile (opening the target
file is enough), and requests are serialized, so every Ctrl+click and
every Ctrl+hover probe waited seconds for a rebuild before JDT was asked.
A tree-sitter check now limits the configuration lookup to positions
inside a @Value annotation's arguments or a getProperty /
getRequiredProperty call's arguments; everything else goes straight to
JDT's textDocument/definition.
YAML/properties keys stayed inside the generic YAML language server, so Spring configuration bindings and their consumers were unreachable from the editor. A new command in the bundled JDT LS extension (java-usages 1.2.0) resolves keys to @ConfigurationProperties members (prefixes, nested/inherited members, records, constructor aliases, collections), @Value placeholders and PropertyResolver calls, and back from Java to configuration entries; Find Usages merges configuration consumers and declarations with the native Java results. Several profiles or modules are offered as candidates. Closes#796.
Co-authored-by: qjlqyf <109515705+qjlqyf@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Find Usages mixed reads and writes of a Java field, including Lombok getter and setter calls, because jdtls has no read/write classification in its references. The usages popup and Find window now have Read and Write toggles. Read-write accesses stay visible in either mode and unclassified results are kept.
Classification comes from a jdtls extension in `plugins/java-usages`, embedded as a jar and installed beside the other bundles. The checked-in jar was rebuilt from source with ECJ and matches byte for byte. Any extension failure falls back to standard references, so a jdtls upgrade can lose the filter but not Find Usages; rebuilding the jar on an upgrade is manual and described in the plugin README. Older installed jars are removed. Other languages keep their plain result count.
Co-authored-by: NingYuanLin <57001533+NingYuanLin@users.noreply.github.com>
l0ng-ai
qiaojianlongandClaude Opus 5.5
Ning YuanLin