Can we really recommend to use the --release option?

[stephan-herrmann]

Initially, it sounded like a cool feature: users can download just one recent JDK and use if for developing various projects targeting various JDK versions, not only in terms of source version but also ensuring that JDK API is used in the exact version specified, e.g., no usage of methods that are not present in the target JDK version etc.

Some of us remember the significant pains required to implement compiler support for --release. Only recently we noticed that it is "tricky" to be consistent in various use cases where some IDE feature resolve JDK types and methods. It is far from trivial to ensure that all use cases are aware of the intended --release version.

Unfortunately, all this will only ever cover use cases working from binary types (.class or .sig). The most elaborate support for --release will invariable fail as soon as we access stuff that exists only in the latest version:

• javadoc attachment
• source attachment

I recently came across a test case where we search for references to some JDK type or method. What if we select to find references within the JDK itself? To locate any index matches and show them in the UI we need to access and resolve source files. What I observed in that particular test case looked like this:

• the project used JDK 23 with --release 16
• from index search we find potential matches within the JDK
• we retrieve the sources for these potential matches from the source attachment
• those source contain plenty of syntax (e.g., sealed), which is illegal at --release 16
• so in trying to be consistent with the project preferences, analyzing sources of those potential matches produces tons of errors, initially syntax errors, and in the sequel also lots of "cannot resolve type X" errors.
• I have no idea how reliable any search result can be in this situation.

This is just an extreme case of the inherent difference between binary and source views of the JDK when --release is involved.

Ergo: Should we generally and strongly discourage this kind of configuration? Should we educate (how?) users that still today there is no better configuration then to use the real JDK of that exact version you are targeting?

[iloveeclipse]

we retrieve the sources for these potential matches from the source attachment

This should be avoided with --release not matching JDK version, as we don't know if the current sources match API at given release. All follow up problems would be ignored then, right?
So where is the place that tries to analyze sources?

[stephan-herrmann]

we retrieve the sources for these potential matches from the source attachment

This should be avoided with --release not matching JDK version, as we don't know if the current sources match API at given release. All follow up problems would be ignored then, right?

So, how can we support search in this situation?

• Disable Search in > JRE Libraries ?
• Add a big red warning "Search results do not reflect the JDK version selected using --release"?
• Show byte code instead? Where to get the correct version?

Actually, I haven't checked what created the index matches in the first place. What do we index?

• the source attachment?
• .sig files from ct.sym (those wouldn't show references in method bodies)?
• .class files of the physical JDK?

@mpalat do you have a ready answer?

[stephan-herrmann]

All follow up problems would be ignored then, right?

Errors detected during search are never reported to the user, but they can easily cause wrong/missing search results.

[iloveeclipse]

Errors detected during search are never reported to the user, but they can easily cause wrong/missing search results.

I have no insights which and how data from attached sources is used, but if we compile with --release not matching JDK we can't use this data in JDT exactly because of that.

If there is something "missing" (what?), it is expected "by design" of --release. One can put a marker on the project saying that using --release not matching current SDK may have some side effects on UI (whatever they are?).

[stephan-herrmann]

One can put a marker on the project saying that using --release not matching current SDK may have some side effects on UI (whatever they are?).

It's the exact purpose of #3168 to improve consistency and minimize the side effects, but right now the extent of what works / can be made to work / doesn't work is quite hard to tell, except: searching within JDK classes seems to be beyond repair.

[stephan-herrmann]

For starters I filed eclipse-jdt/eclipse.jdt.ui#2017

[iloveeclipse]

Should we generally and strongly discourage this kind of configuration?

Would be a killer for our product development, because we officially support two recent LTS JDK versions (17 and 21) and compile with --release 17 while running on Java 21+.

[stephan-herrmann]

Should we generally and strongly discourage this kind of configuration?

Would be a killer for our product development, because we officially support two recent LTS JDK versions (17 and 21) and compile with --release 17 while running on Java 21+.

Sorry to be the bearer of bad news.

[stephan-herrmann]

• we retrieve the sources for these potential matches from the source attachment
• those source contain plenty of syntax (e.g., sealed), which is illegal at --release 16
• so in trying to be consistent with the project preferences, analyzing sources of those potential matches produces tons of errors, initially syntax errors, and in the sequel also lots of "cannot resolve type X" errors.

If there is a strong need, we could investigate, if MatchLocator could possibly switch compliance levels in mid-air, i.e., when processing sources from a JDK source attachment temporarily switch to the compliance of the physical JDK, and switch back for other sources. Theory speaking. I can't promise that this is feasible.