Rewrite quickfix doesn't resolve types coming from the same source folder

[BoykoAlex]

Use spring-data-aot project
Invoke code action to add query annotation in CoffeeRepository class over this method:

List<Coffee> findBySizeAndPriceGreaterThan(Size size, BigDecimal price);

No query annotation added on the client and NPE on WorkspaceEdit on the server is the result.

The problem is that recipe doesn't produce changes. The issue is that Size type is unresolved although it is available via the project source. The Rewrite Java parser needs types stubs for sources in the code base to be able to resolve types in the source being parsed which is just the repository class.

[BoykoAlex]

I finally understand the issue. STS or Boot LS runs on Java 21 while the project is Java 25 based. Now when source is parsed Rewrite's limitation is that effectively java parser can be created for java version >= the running java version. Therefore, the code is being attempted to be parsed with Java 21 parser this generally succeeds except for the classpath entries which a .class compiled with higher java version compiler (i.e. java 25 in this case). The result is that types from sources in the project becomes unresolved for the current source being parsed hence failures to find methods etc. The workaround is launch STS/Boot LS with Java 25 which be default would be the case anyway.
@martinlippert we can ignore this issue (as we are phasing out Rewrite) or push in my local fix that modifies the recipe such that it doesn't need resolved types to match methods...

[martinlippert]

I can see that vscode-java still ships with a JRE 21, so I asked them if we they could update to a recent JDK 25 (redhat-developer/vscode-java#4353).

But I also think that this "under the hood dependency" between the JRE that is used to run the LS and the JDK that is used/required by projects is a giant architecture smell. The Gradle tooling has the same issues and problems around this mismatch come up over and over again.

@BoykoAlex back to your question, we should probably include a workaround here for the moment, since we can't solve the underlying architectural issue in the short team. The "real fix" will be to fully replace the OR usage, but that will take a little while.