LSP4Jakarta should not be relying on an internal JDT class, since changes can be made at any time that can break existing functionality. We should try to find an alternative to using the internal JDT class for retrieving the import declaration information.
To reproduce this issue, you can use Liberty Tools for VS Code version 23.0.12 with VS Code version 1.86.1 and Language Support for Java(TM) by Red Hat version 1.27.0.
As you can see in the screen shot below, completion/snippet support is available, but there are no diagnostics on the getMethod or postMethod as would be expected since they cannot be private. As a consequence of no diagnostics, there are also no quick fixes provided.
Stacktrace from Language Support for Java extension:
[Error - 12:45:33 PM] Feb. 13, 2024, 12:45:33 p.m. Error in calling delegate command handler
'java.lang.Object org.eclipse.jdt.internal.core.JavaModelManager.getInfo(org.eclipse.jdt.core.IJavaElement)'
java.lang.NoSuchMethodError: 'java.lang.Object org.eclipse.jdt.internal.core.JavaModelManager.getInfo(org.eclipse.jdt.core.IJavaElement)'
at org.eclipse.lsp4mp.jdt.core.utils.AnnotationUtils.isMatchAnnotationFullyQualifiedName(AnnotationUtils.java:174)
at org.eclipse.lsp4mp.jdt.core.utils.AnnotationUtils.isMatchAnnotation(AnnotationUtils.java:137)
at org.eclipse.lsp4mp.jdt.core.utils.AnnotationUtils.getAnnotation(AnnotationUtils.java:73)
at org.eclipse.lsp4mp.jdt.core.utils.AnnotationUtils.getAnnotation(AnnotationUtils.java:104)
at org.eclipse.lsp4mp.jdt.core.jaxrs.JaxRsUtils.getJaxRsApplicationPathValue(JaxRsUtils.java:82)
at org.eclipse.lsp4mp.jdt.core.jaxrs.JaxRsContext$1.collectApplicationPath(JaxRsContext.java:190)
at org.eclipse.lsp4mp.jdt.core.jaxrs.JaxRsContext$1.acceptSearchMatch(JaxRsContext.java:185)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.report(MatchLocator.java:2205)
at org.eclipse.jdt.internal.core.search.matching.TypeReferenceLocator.matchReportReference(TypeReferenceLocator.java:537)
at org.eclipse.jdt.internal.core.search.matching.TypeReferenceLocator.matchReportReference(TypeReferenceLocator.java:366)
at org.eclipse.jdt.internal.core.search.matching.OrLocator.matchReportReference(OrLocator.java:314)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2713)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:3180)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2886)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:2058)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1369)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1406)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1549)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:134)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:253)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:599)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:669)
at org.eclipse.lsp4mp.jdt.core.jaxrs.JaxRsContext.findApplicationPath(JaxRsContext.java:177)
at org.eclipse.lsp4mp.jdt.core.jaxrs.JaxRsContext.getApplicationPath(JaxRsContext.java:114)
at org.eclipse.lsp4mp.jdt.internal.jaxrs.java.JaxRsCodeLensParticipant.beginCodeLens(JaxRsCodeLensParticipant.java:75)
at org.eclipse.lsp4mp.jdt.internal.core.java.codelens.JavaCodeLensDefinition.beginCodeLens(JavaCodeLensDefinition.java:53)
at org.eclipse.lsp4mp.jdt.core.PropertiesManagerForJava.lambda$1(PropertiesManagerForJava.java:195)
at java.base/java.util.ArrayList.forEach(Unknown Source)
at org.eclipse.lsp4mp.jdt.core.PropertiesManagerForJava.collectCodeLens(PropertiesManagerForJava.java:195)
at org.eclipse.lsp4mp.jdt.core.PropertiesManagerForJava.codeLens(PropertiesManagerForJava.java:176)
at org.eclipse.lsp4mp.jdt.internal.core.ls.MicroProfileDelegateCommandHandlerForJava.getCodeLensForJava(MicroProfileDelegateCommandHandlerForJava.java:248)
at org.eclipse.lsp4mp.jdt.internal.core.ls.MicroProfileDelegateCommandHandlerForJava.executeCommand(MicroProfileDelegateCommandHandlerForJava.java:90)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:220)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:616)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Changes to the JavaModelManager class here... https://github.com/eclipse-jdt/eclipse.jdt.core/commit/4556ac22b87bd69828fed9fbcf8ce24c24fad2ec#diff-c8cd805ea463f0b6ca1b6b31a5769d1a25eff919b513631fb3dd48c1d7c962c7 ... have caused diagnostics to break, since LSP4Jakarta is relying on the
getInfo
method to return anObject
here... https://github.com/eclipse/lsp4jakarta/blob/main/jakarta.jdt/org.eclipse.lsp4jakarta.jdt.core/src/main/java/org/eclipse/lsp4jakarta/jdt/internal/DiagnosticUtils.java#L121-L125LSP4Jakarta should not be relying on an internal JDT class, since changes can be made at any time that can break existing functionality. We should try to find an alternative to using the internal JDT class for retrieving the import declaration information.
To reproduce this issue, you can use Liberty Tools for VS Code version 23.0.12 with VS Code version 1.86.1 and Language Support for Java(TM) by Red Hat version 1.27.0.
As you can see in the screen shot below, completion/snippet support is available, but there are no diagnostics on the
getMethod
orpostMethod
as would be expected since they cannot beprivate
. As a consequence of no diagnostics, there are also no quick fixes provided.Stacktrace from Language Support for Java extension: