feat: add setting to show generated code in document symbols#4335
Merged
datho7561 merged 1 commit intoFeb 24, 2026
Merged
Conversation
fbricon
force-pushed
the
show-generated-code-in-outline
branch
from
4d875ee to
4c56aac
Compare
Signed-off-by: Fred Bricon <fbricon@gmail.com>
fbricon
force-pushed
the
show-generated-code-in-outline
branch
from
4c56aac to
5c42f13
Compare
datho7561
approved these changes
Feb 24, 2026
Contributor
datho7561
left a comment
datho7561
left a comment
There was a problem hiding this comment.
Looks good. Thanks, Fred!
This was referenced Apr 28, 2026
a-simeshin
added a commit
to a-simeshin/serena
that referenced
this pull request
May 5, 2026
JDTLS' DocumentSymbolHandler filtered out every SourceMethod where JDTUtils.isGenerated() was true, so Lombok-synthesised methods (getX/setX, builder(), equals/hashCode/toString, withX, fluent accessors, ...) never reached the LSP client. As a result Serena's symbol-aware tools — find_symbol, get_symbols_overview, replace_symbol_body, insert_before_symbol, insert_after_symbol — could not see, address or edit any Lombok-generated member; only search_for_pattern / replace_content (text-based) worked. Upstream introduced an opt-in preference java.symbols.includeGeneratedCode in eclipse-jdtls/eclipse.jdt.ls#3706 (merged 2026-02-24) and surfaced it through redhat-developer/vscode-java#4335. First vscode-java release with the new JDTLS build is v1.53.0 (2026-02-26). Serena was pinned to v1.42.0-561, well before the fix existed. Changes: - New ls_specific_settings.java.lombok_show_generated setting (default true); forwarded to JDTLS as java.symbols.includeGeneratedCode in initialize params. Older servers ignore the unknown preference key silently. - Bump bundled vscode-java DEFAULT 1.42.0-561 -> 1.54.0-923 (brings JRE 21.0.10, Lombok 1.18.39 and Equinox launcher 1.7.100). INITIAL stays at 1.42.0-561, so per the per-version install-dir convention from oraios#1438 the new build lands in vscode-java-1.54.0-923/ while legacy vscode-java/ caches and any explicit vscode_java_version: '1.42.0-561' override keep working. - New VsixResourcePaths dataclass + INITIAL/DEFAULT_VSCODE_JAVA_PATHS pin the JRE / Lombok / launcher filenames *inside* the VSIX. Without this, bumping the archive would break users on legacy 1.42.0-561 because resource paths inside the archive change between releases. Resolution mirrors SHA pinning: known versions get their pinned paths; any other version raises SolidLSPException with a pointer to upstream-jdtls mode (which derives paths dynamically and needs no pinning). - Drop dead 'static/vscode-java/...' placeholder in initialize params; the real runtimes[] is overwritten below from runtime_dependency_paths .jre_home_path, which is correct in both default-VSIX and upstream-jdtls modes. - Test fixtures: Lombok provided dep in test_repo/pom.xml plus LombokModel / FluentLombokModel / DefaultGreeter covering @DaTa, @builder (toBuilder=true), @with, @DeleGate, @AllArgsConstructor, @NoArgsConstructor and @accessors(fluent=true). Regression test in test_java_basic.py asserts every generated-method shape lands in document symbols. Closes oraios#1432
MischaPanch
pushed a commit
to oraios/serena
that referenced
this pull request
May 5, 2026
…mp jdtls version (#1434) * feat(jdtls): surface Lombok-generated methods in document symbols JDTLS' DocumentSymbolHandler filtered out every SourceMethod where JDTUtils.isGenerated() was true, so Lombok-synthesised methods (getX/setX, builder(), equals/hashCode/toString, withX, fluent accessors, ...) never reached the LSP client. As a result Serena's symbol-aware tools — find_symbol, get_symbols_overview, replace_symbol_body, insert_before_symbol, insert_after_symbol — could not see, address or edit any Lombok-generated member; only search_for_pattern / replace_content (text-based) worked. Upstream introduced an opt-in preference java.symbols.includeGeneratedCode in eclipse-jdtls/eclipse.jdt.ls#3706 (merged 2026-02-24) and surfaced it through redhat-developer/vscode-java#4335. First vscode-java release with the new JDTLS build is v1.53.0 (2026-02-26). Serena was pinned to v1.42.0-561, well before the fix existed. Changes: - New ls_specific_settings.java.lombok_show_generated setting (default true); forwarded to JDTLS as java.symbols.includeGeneratedCode in initialize params. Older servers ignore the unknown preference key silently. - Bump bundled vscode-java DEFAULT 1.42.0-561 -> 1.54.0-923 (brings JRE 21.0.10, Lombok 1.18.39 and Equinox launcher 1.7.100). INITIAL stays at 1.42.0-561, so per the per-version install-dir convention from #1438 the new build lands in vscode-java-1.54.0-923/ while legacy vscode-java/ caches and any explicit vscode_java_version: '1.42.0-561' override keep working. - New VsixResourcePaths dataclass + INITIAL/DEFAULT_VSCODE_JAVA_PATHS pin the JRE / Lombok / launcher filenames *inside* the VSIX. Without this, bumping the archive would break users on legacy 1.42.0-561 because resource paths inside the archive change between releases. Resolution mirrors SHA pinning: known versions get their pinned paths; any other version raises SolidLSPException with a pointer to upstream-jdtls mode (which derives paths dynamically and needs no pinning). - Drop dead 'static/vscode-java/...' placeholder in initialize params; the real runtimes[] is overwritten below from runtime_dependency_paths .jre_home_path, which is correct in both default-VSIX and upstream-jdtls modes. - Test fixtures: Lombok provided dep in test_repo/pom.xml plus LombokModel / FluentLombokModel / DefaultGreeter covering @DaTa, @builder (toBuilder=true), @with, @DeleGate, @AllArgsConstructor, @NoArgsConstructor and @accessors(fluent=true). Regression test in test_java_basic.py asserts every generated-method shape lands in document symbols. Closes #1432
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
2 participants
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.
New
java.symbols.includeGeneratedCodeboolean setting to enable returning generated code in document symbols.Requires eclipse-jdtls/eclipse.jdt.ls#3706
Fixes #4084
Because there's no way to programmatically trigger an outline view refresh (see microsoft/vscode#108722), after changing the setting you need to close/reopen the java files, or make a dummy change to see the updates in the outline view.