Consider Java 17 as BREE

[mickaelistria]

Java 17 is LTS, JustJ ships support for it so it would still run well in recent Eclipse IDE packages, and it has tons of good features that TM4E could leverage.
So this is a call to active contributors (as per https://projects.eclipse.org/projects/technology.tm4e/who ): @sebthom @akurtakov @danipen would you be in favor of moving to Java 17 as BREE to leverage its new features?

[akurtakov]

I'm fine with the proposal in general. Do you guys think we should announce it wider now (cross-project?) with goal being to do so for September release?
If you're all set on that and want to do it right now so be it. IMO such change that affects many projects using it is better delivered in M1 though.

[mickaelistria]

I've announced that intent to appropriate mailing-lists so that downstream consumers can be prepared.

[martinlippert]

I would like to draw your attention to eclipse-buildship/buildship#1147 from the Buildship project, which describes basically a tight coupling between the JRE that is used to run the IDE and the version of Gradle that a project uses and which has certain JRE compatibilities (the Gradle version of the project MUST support the JRE of the IDE).

To cut a long story short: as long as this issue isn't resolved (and I don't expect this to be resolved anytime soon), users continue to have two options to workaround this limitation in buildship:

• they upgrade the Gradle version of each project (to make the IDE happy)
• they change the JRE to run the IDE (to make the projects happy)

(very short and sloppy summary here, for more details please refer to the Buildship issue mentioned above)

An upgrade of TM4E to require a Java 17 as BREE would remove (more or less) the second option. The only choice would be to upgrade project definitions (or to not use Buildship, of course).

So I think an upgrade of TM4E to require Java 17 as BREE has some wider consequences, so having more time for people involved to mitigate those consequences (in one way or the other) would be great.

[mickaelistria]

@martinlippert I suggest you share this with the cross-project-issues-dev mailing-list for a wider audience.

[akurtakov]

Do we have an agreement that TM4E delivers Java 11 based release for 2022-06 and switch to Java 17 after that?

[mickaelistria]

Yes, next release will support Java 11 and is due this month to get into 2022-06; then we switch to Java 17.
@sebthom As you're doing most of the work, please ping when you think it's the best time for a release.

[sebthom]

@mickaelistria I think I am done for now. Before tackeling #38 I want to wait for the next release of vscode-textmate where they did quite some refactoring.

[mickaelistria]

OK. So you're OK if we release right now? And then we start bumping BREEs and adopting relevant newer Java constructs and APIs on master after that?

[sebthom]

That is fine with me.

[mickaelistria]

I started the process of releasing TM4E but a review will be required this time, so that adds a few days of delay.

[mickaelistria]

Done with #395