Hey! Thanks a lot for bringing this to the wider audience, much appreciated.
I added a comment around a somewhat unpleasant consequence of an upgrade to JavaSE-17 as a minimal Java version: https://github.com/eclipse/tm4e/issues/339#issuecomment-1102875590 <https://github.com/eclipse/tm4e/issues/339#issuecomment-1102875590> Which draws the attention to the tight coupling between the JRE that is used to run the IDE and the version of Gradle that users use in their projects (caused by the Buildship integration): https://github.com/eclipse/buildship/issues/1147 <https://github.com/eclipse/buildship/issues/1147> Not sure what the best approach here is (beyond fixing the coupling that Buildship causes)… But probably worth to draw some attention to… :-) Cheers Martin > Am 19.04.2022 um 16:25 schrieb Mickael Istria <mist...@redhat.com>: > > Hi all, > > In https://github.com/eclipse/tm4e/issues/339 > <https://github.com/eclipse/tm4e/issues/339> , active TM4E contributors have > agreed to consider the move the JavaSE-17 as minimal Java version soon. The > rationale is that some benefits of recent version of Java languages (sealed > Types, switch expressions....) are likely to really facilitate further > maintenance and development of the parsers included in TM4E, and also to > increase quality (new constructs leave less space for bugs, and often perform > better). So we can expect a substantial gain for TM4E future in adopting Java > 17 soon. > > I'm sharing this with Simultaneous Release channel as TM4E is part of SimRel. > At the moment, SimRel targets Java 11. So when TM4E is released with Java 17 > requirement, either SimRel allows that and the new release gets in; or SimRel > keeps Java 11 requirement and will use an older version of TM4E (for which > there would probably have no support given currently active contributors are > happy moving to Java 17). > TM4E is used by Wild Web Developer for instance; but Wild Web Developer > doesn't mandate 1 specific version of TM4E and we plan to keep TM4E backward > compatible in term of behavior and API; so those downstream consumers should > be able to work with former (Java 11-able) release as well as newer (Java > 17-able) release. So I don't think that downstream consumption should be a > main concern. > > I would invite SimRel stakeholders to consider is whether/when to allow Java > 17-based code in SimRel. > Of course, I would advocate for "Do it right now" especially since JustJ and > thus SimRel and EPP packages ships a recent Java; but acknowledge that this > may require more discussion, hence why I'm sharing this plan for TM4E early. > > Cheers, > > -- > Mickael Istria > Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat > Developers > <https://developers.redhat.com/>_______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
