Re: [eclipse.org-planning-council] Allow Java 17 as BREE in SimRel
The version of each product in the generated catalog is computed
from the metadata in the product IUs, i.e., looking for this
private static final String JAVA_VERSION_PREFIX =
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).
On 19.04.2022 17:15, Jonah Graham
Hi Planning Council,
Please see the conversation initiated by Mickael/TM4E
First a question:
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
- EPP already bundles Java 17, so new downloads of packages
won't be a problem (assuming scout resolves )
- 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 <
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.
, 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
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
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.
cross-project-issues-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
eclipse.org-planning-council mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council