Prefer not to search for references within JRE when using --release

[stephan-herrmann]

Reference search operates on sources, but when using --release X while only a JDK Y (Y>X) is installed / configured, then no sources of the desired version are available.

Possible impact:

• finding references which don't exist in the desired JDK version
• not being able to process some sources because they have syntax errors when compiled at the given release level.

For that reason I suggest that the Java Search dialog should detect this situation and when --release doesn't match the physical JDK then

• by default disable Search In > JRE libraries
• if the above is enable by the user raise a warning about the incompatibility ("cannot show search results exactly matching the configured release version" or similar).

[jukzi]

On the other hand: Even if the release options refers to another JDK, then the available/used JDK will still call the method, so it is actually referenced at runtime.

[iloveeclipse]

On the other hand: Even if the release options refers to another JDK, then the available/used JDK will still call the method, so it is actually referenced at runtime.

Not sure what you mean. If it is a different method, we can't refer to actual JDK which compiler is using currently, because it may not exist here / changed signature etc. So if it is incompatible / not existing method in the current JDK, it will be not called by current JDK because it is technically not possible. This is the main point of the --release option.

[jukzi]

Probably 99% signatures will not depend on JDK version but those would be excluded from search just because some may have changed.

[iloveeclipse]

Probably 99% signatures will not depend on JDK version but those would be excluded from search just because some may have changed.

Check ct.sym content. If that would be 99% we would not have so many files there. For user it doesn't matter if it is 1% or 10%, the data we use would be seemingly "randomly" correct or incorrect...

[stephan-herrmann]

On the other hand: Even if the release options refers to another JDK, then the available/used JDK will still call the method, so it is actually referenced at runtime.

Not sure what you mean. If it is a different method, we can't refer to actual JDK which compiler is using currently, because it may not exist here / changed signature etc. So if it is incompatible / not existing method in the current JDK, it will be not called by current JDK because it is technically not possible. This is the main point of the --release option.

Using --release 17 at compile time ensures that we are calling only those methods that really exist at 17. But the physical JDK (e.g., 23) used during development may have a different implementation of that method, and it has additional methods. Search using the method bodies of the physical JDK rather than the intended target JDK may be off in arbitrary ways.

[jjohnstn]

@stephan-herrmann I have posted a patch which check for --release being set lower than default JRE and a warning is issued on the Java Search page. Let me know if this satisfies what you were looking for and if any tweaks are needed.

[stephan-herrmann]

@stephan-herrmann I have posted a patch which check for --release being set lower than default JRE and a warning is issued on the Java Search page. Let me know if this satisfies what you were looking for and if any tweaks are needed.

From a first glimpse this looks good. I'll check out the branch to see it in action soonish.