| Re: [eclipse.org-planning-council] Allow Java 17 as BREE in SimRel |
_______________________________________________"hopefully new Java releases will be less disruptive..."
Winter is coming when they remove security manager APIs altogether.
Tom
From: eclipse.org-planning-council <eclipse.org-planning-council-bounces@xxxxxxxxxxx> on behalf of Ed Merks <ed.merks@xxxxxxxxx>
Sent: Wednesday, April 20, 2022 2:41 AM
To: eclipse.org-planning-council@xxxxxxxxxxx <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse.org-planning-council] Allow Java 17 as BREE in SimRelThis Message Is From an External SenderThis message came from outside your organization.This sounds like a reasonable approach and 2022-09 sounds reasonable as well.
+1
I hope though that dependencies low in the stack don't move so quickly. I know for a fact that some companies building RCP applications have not yet recovered from the the Java 11 bump; hopefully new Java releases will be less disruptive in terms of being backward compatible and then this will be less of a concern...
On 20.04.2022 07:03, Aleksandar Kurtakov wrote:
On Wed, Apr 20, 2022 at 1:17 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> IMO, coming to such an agreement is what we should be looking for right now so we can set up some expectations .
Such an agreement would be a good outcome.
6-9 months after LTS release would be 2022-06 - although I think for Java 17 the clock should start once we make a decision + announcement, so concretely 2022-12 if we decide soon enough.
I don't think we can delay things due to not having planned early enough or being late to make a decision. In this particular case I would say 2022-09 should be the case - I'm not thrilled to release WWD, Dockertools and etc. with already unsupported version of TM4E.
Therefore for next LTS, Java 21 in Sept 2023, we would update max BREE in 2024-06 release.
How is that for a first pass at a concrete proposal?
+1
_______________________________________________On Tue, 19 Apr 2022 at 15:21, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:
_______________________________________________
On Tue, Apr 19, 2022 at 7:56 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Thanks Ed.
That is good to know.
> of the benefits of using Java 17 (for one project).
For the record - not just one project - TM4E is just the first project, but I find myself on a regular basis wanting some of the key Java 17 features (especially text blocks and better NPE error messages, but switch expressions, instanceof and other improvements are nice too!). I would love to update CDT, and LSP4J - the latter is still on Java 8, but the next release will be Java 11.
+1 . It's a constant struggle trying to balance between the let's keep oldest possible Java compatibility and let's use all features from latest Java camps. For that we need some clear and hopefully predictable balance - something like allowing the latest Java LTS 6-9 months after its release is a good one IMHO as it gives time for adjustment and will still allow getting new contributors (who AFAICS are mostly wanting to use latest and greatest).IMO, coming to such an agreement is what we should be looking for right now so we can set up some expectations . This doesn't mean we will not lose some projects who don't want to move so slow|fast but I can't see how we can come with smth better than that.
Also, it would be good for projects to develop and test with the version that we ship with.
I recognize it is going to be a while, but it would be nice if we got to Java 17 before Java 21 came out.
Jonah
_______________________________________________On Tue, 19 Apr 2022 at 12:39, Ed Merks <ed.merks@xxxxxxxxx> wrote:
_______________________________________________FYI,
The version of each product in the generated catalog is computed from the metadata in the product IUs, i.e., looking for this touchpoint:
private static final String JAVA_VERSION_PREFIX = "addJvmArg(jvmArg:-Dosgi.requiredJavaVersion=";
So if you change the product definitions, that will be automatically be picked up.
I believe that Mickael has added logic that detects the actual Java version of the running IDE and complains if it's not compatible with the BREE of something you are trying to install so that's not a big problem.
That being said, I think we should carefully consider being less disruptive for our downstream community, while we still have one, and balance the need for stability against the significance of the benefits of using Java 17 (for one project).
Regards,
Ed
On 19.04.2022 17:15, Jonah Graham wrote:
Hi Planning Council,
Please see the conversation[0] initiated by Mickael/TM4E project.
First a question:Is there some restriction as to what BREE a bundle can have in SimRel. I don't see one in https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
If there is a restriction, how has the planning council bumped it in the past?
Regardless, what, if any, are the downsides to having some bundles with Java 17 as BREE?
My first pass at brainstorming the issue:- 9 of the 11 EPP packages contain TM4E (only modeling and parallel don't)
- EPP already bundles Java 17, so new downloads of packages won't be a problem (assuming scout resolves [1])- Installer needs to know what JVM versions to allow. I assume this is now based solely on the Product Version.- Updates will be similar in scope to the Java 8 -> Java 11 transition. A lot of work was done at that time to make everything handle the case. Biggest change is now probably how to update bundled JustJ for people who are still on JustJ < 17.[2]
I suppose at some point the Eclipse Platform will update some bundle to Java 17 and the decision will be made for SimRel. In this case we have a small, but significant, project that wants to transition. On the flip side, I expect the people still bothered by the Java 8 -> Java 11 transition to not be pleased either.
Initially I want to start a discussion on this topic - if there is something that needs a formal council vote we can do that once we understand the problem space a bit better.
[0] https://www.eclipse.org/lists/cross-project-issues-dev/msg19126.html - the first message of which is quoted below[2] * The JustJ is somewhat an orthogonal problem https://bugs.eclipse.org/bugs/show_bug.cgi?id=570899
Jonah
---------- Forwarded message ---------
From: Mickael Istria <mistria@xxxxxxxxxx>
Date: Tue, 19 Apr 2022 at 10:25
Subject: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 as BREE soon
To: tm4e developer discussions <tm4e-dev@xxxxxxxxxxx>, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
_______________________________________________Hi all,
In 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,
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
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
--
Aleksandar KurtakovRed Hat Eclipse Team
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
--
Aleksandar KurtakovRed Hat Eclipse Team
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council