Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 as BREE soon
Just because some bundles are J17 don't mean everyone will need J17 if consuming "simrel", I assume there is no one really building a product that contains *ever* simrel project.
So lets assume there is a never java 17 version in simrel, and you want to stick with java 11, then you can simply use that part from an earlier simrel. In the end this is not different from keeping the old java 11 version in simrel and publish a "non simrel" java 17 release.
So from my point of view it does not makes much sense to keep older releases in simrel and publish newer ones of it unless you plan to contribute bugfix releases to the java 11 one in parallel, that's what releases are for that people can still use the old stuff if you moved ahead... otherwise one update-site could be used for a rolling release and eclipse could save a lot of storage-space ;-) 

Am 19.04.22 um 20:34 schrieb Torbjorn SVENSSON via cross-project-issues-dev:

Hello,

Is it only me that sees problems for downstream consumers of the SimRel? I mean, what happens if you use the SimRel as a way to define a stable target platform for your product?
As long as the BREE of the plugins is not newer than version X will allow the product to run with JRE of that version "X".
What you are talking about here is more or less requiring anyone using SimRel to also move to a JRE 17. I think that's okay to do, but there should be some heads up for this type of change as it can cause major problem for our downstream consumers.

My 2 cents is that the newest BREE allowed in SimRel should be the same version that is said to be the required JRE version to run the Eclipse IDE (AFAIK, that's JRE 11 ATM).

Kind regards,
Torbjörn


ST Restricted

-----Original Message-----
From: cross-project-issues-dev <cross-project-issues-dev-bounces@xxxxxxxxxxx> On Behalf Of Christoph Läubrich
Sent: den 19 april 2022 19:16
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 as BREE soon

  > I would be very keen to allow Java 17 as BREE in SimRel by a project
  > that wants it.
  > PS Where is "SimRel targets Java 11" defined? Is it just implicit
  > at the moment (because Eclipse Platform is Java 11),

I think there is at least no *technical* reason of this, as far as I
know there are still bundles targeting Java 8 (or even 6), one should
only keep in mind that if Eclipse is run with JDK11 then it would
require users to install never version if they want install such Java 17
stuff (probably that will be automated with the JustJ updatesite
included), so maybe there is nothing special to consider?



Am 19.04.22 um 16:37 schrieb Jonah Graham:

Thank you Mickael for starting this discussion.

I would be very keen to allow Java 17 as BREE in SimRel by a project
that wants it. I will endeavour to get the Planning Council to come to
an agreement on this as I think that is the group in charge of such
requirements.

PS Where is "SimRel targets Java 11" defined? Is it just implicit at the
moment (because Eclipse Platform is Java 11), or is it explicit
somewhere? The only requirement on this topic in the SimRel Release
Requirements is that bundles have a BREE[1]

[1]
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29>

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>


On Tue, 19 Apr 2022 at 10:25, Mickael Istria <mistria@xxxxxxxxxx
<mailto:mistria@xxxxxxxxxx>> wrote:

     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@xxxxxxxxxxx
     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
     To unsubscribe from this list, visit
     https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
     <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top