Some dynamic discovery for environment versions#663
Some dynamic discovery for environment versions#663mickaelistria wants to merge 1 commit intoeclipse-jdt:masterfrom
Conversation
Provides some capability for environments that are not yet statically described in JDT. This is a step towards eclipse-jdt#661
| } else if (desc.indexOf("1.0") != -1) { //$NON-NLS-1$ | ||
| return "1.0"; //$NON-NLS-1$ | ||
| } else { | ||
| // an optimistic strategy for not-yet-declared versions |
There was a problem hiding this comment.
That produces 1 from 25.0.1, and that is really guessing...
I'm not sure this is the right way to guess the version out of EE.
The entire method looks like a big hack.
Why can't we add an extra "JavaCompliance" attribute to org.eclipse.jdt.launching.executionEnvironments extension point and specify there all what we need?
There was a problem hiding this comment.
That produces 1 from 25.0.1, and that is really guessing..
The current code would also return 24 for 1.0.24, so it's not so much worse...
Why can't we add an extra "JavaCompliance" attribute to org.eclipse.jdt.launching.executionEnvironments extension point and specify there all what we need?
We sure can, but usually, this happens on a branch that takes ages before it is merged...
2 participants
What it does
Provides some capability for environments that are not yet statically described in JDT.
This is a step towards
#661
How to test
Just ensure no regressions.
Because further guards are in place (eg checking Compiler support for given EE compliance), this would usually be a no-op as for the EE to be returned by the EEManager, the compiler must also declare support for next version.
Author checklist