User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
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...
> 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?
> 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.
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.
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.
----------
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.