Latest release of Eclipse JDT breaks diagnostics due to usage of internal JDT class

[TrevCraw]

Changes to the JavaModelManager class here...
eclipse-jdt/eclipse.jdt.core@4556ac2#diff-c8cd805ea463f0b6ca1b6b31a5769d1a25eff919b513631fb3dd48c1d7c962c7
... have caused diagnostics to break, since LSP4Jakarta is relying on the getInfo method to return an Object 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-L125

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)

[mezarin]

This issue should be fixed in version 0.2.1 (PR #518). Closing this issue.