Add AST getAll[Supported]Versions and isSupportedVersion

[akurtakov]

New methods to ease finding all/supported JLS versions. Supported JLS versions helpers are needed in order ease limiting AST support to what compiler supports.

[akurtakov]

eclipse-jdt/eclipse.jdt.ui#1948 is an example of usage of new API.

[akurtakov]

@iloveeclipse IIRC you added the similar API in JavaCore so would you please take a look.

[iloveeclipse]

Should it be SUPPORTED_VERSIONS ?

[akurtakov]

Using SUPPORTED_VERSIONS should happen in #3533 together with switching the mapping to prevent inconsistencies.

[iloveeclipse]

LGTM, but I've never worked within AST area, so no idea what is supposed to be supported or not. So would be nice if someone familiar with AST could review too,

[akurtakov]

I'll wait Monday and push it if no one jumps in.

[stephan-herrmann]

I found this only now.

@akurtakov this adds to the set of locations that need to be touched whenever a new Java version is supported. We already have org.eclipse.jdt.core.dom.AST.JLS_INTERNAL_Latest and getJLSLatest() which should encapsulate the moving target. Why do we now need another explicit list?

[akurtakov]

@stephan-herrmann Here yes but e.g. in eclipse-jdt/eclipse.jdt.ui#1966 it removes one such place (the goal is to have jdt.ui/debug need less or even no changes for adding constants).
Supported versions is also used in #3533 and simplifies AST constructor and removes(automates) one more place in ASTTest(which was stuck to Java 20 !). Overall, for the JDT project it would be a decrease.

[stephan-herrmann]

@stephan-herrmann Here yes but e.g. in eclipse-jdt/eclipse.jdt.ui#1966 it removes one such place (the goal is to have jdt.ui/debug need less or even no changes for adding constants). Supported versions is also used in #3533 and simplifies AST constructor and removes(automates) one more place in ASTTest(which was stuck to Java 20 !). Overall, for the JDT project it would be a decrease.

I didn't argue against providing this API, I only wonder why it needs to be implemented using an explicit list.

[akurtakov]

My reasons were:

• match JavaCore SUPPORTED_VERSION implementation so codebase has a more unified way of handling similar problems
• keep possibility to e.g. keep only LTS versions support (unlikely but still) e.g at some point 8, 11, 17, 18....n are supported.

[stephan-herrmann]

My reasons were: ...

Thanks.

I had hoped we could do with less duplication, but for now I added the new locations needing updates to https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/Adding-support-for-new-Java-version-and-Features-in-JDT (also JavaCore.allVersions was missing) . It's a pity that this list seems to be growing monotonously, never shrinking.