Autocompletion suggest methods that are outside of the desired compliance level (and then fails to compile)

[fedejeanne]

The problem

I get autocompletion proposals that are outside the compliance level specified in the project, e.g.

The method java.util.concurrent.Executors.newThreadPerTaskExecutor(ThreadFactory) is available starting with Java 21 but the compliance level is set to 17.

To reproduce

Option Nr. 1

• Use JDK 17
• Write Executors.newT and open autocompletion

Option Nr. 2

• Use JDK > 17 (I used 21)
• Set the Compiler compliance Level to 17 via project properties
• Write Executors.newT and open autocompletion

[jukzi]

i think that its not a bug, you are supposed to used a jdk17. Also it may not be solvable otherwise as the since-version annotation does not provide a comparable value.

[jukzi]

nevertheless the behavior feels inconsistent between ui and core.
Duplicates the ui issue eclipse-jdt/eclipse.jdt.ui#1630

[fedejeanne]

i think that its not a bug, you are supposed to used a jdk17.

Ah, good tip. I was using JRE for JavaSE-17, which showed up as JavaSE-17 in the package explorer but it seems to resolve to something with Java 21 (or maybe even 23).

Once I specifically selected temurin-jdk-17.0.13+11 [perfect match] in the preferences, the problem vanished.

Nevertheless the behavior is odd IMO. What does the Compiler Compliance Level do if not these kind of stuff?

[jukzi]

Nevertheless the behavior is odd IMO. What does the Compiler Compliance Level do if not these kind of stuff?

i guess it selects java language features of the parser

[fedejeanne]

Nevertheless the behavior is odd IMO. What does the Compiler Compliance Level do if not these kind of stuff?

i guess it selects java language features of the parser

... in English please? 😅

[jukzi]

for example the use of "var" or for-each-loop, try-with-resource, pattern matching in case statements. That are java language features that do not require a jdk