| Re: [gef-dev] Java 21 for GEF-Classic |
> As I understand it, Tycho will run tests using the
configured Java 17 in the tool chain if the project says its test
runs on Java 17.
That's how it's supposed to work but after playing around with it for a while, I can say with high confidence that it'll fail for two reasons:
1) We have integration tests that launch the Eclipse IDE. Because the IDE requires Java 21, the tests now also require Java 21.
2) Because Tycho has to be run with Java 21, the tests will always be executed with Java 21, even if explicitly told to consider the BREE (which is still set to Java 17).
A few years ago I worked on a product that was still using Java
11, but we had to use Tycho 3.x and therefore built with Java 17.
Meaning that this behavior is very likely a regression in Tycho.
> I personally prefer that we also consider the consumers who are generally best served with the least restrictive requirements.
That's a fair point. Then perhaps let's approach it from a different perspective: What plugins have to be executed with Java 21?
- As mentioned, we have the test fragments.
- We also have the documentation. It doesn't make sense to use
them without the Eclipse Help, so they should probably also
require Java 21, even if they only contain HTML.
- For GEF, I'm also leaning towards Java 21, as it depends on the
Eclipse Platform. Which is currently a real pain to configure
without accidentally pulling in a Java 21 bundle...
- For Draw2D and Zest, I'd then stick to Java 17 for the time
being, as they only depend on SWT/JFace.
I personally prefer that we also consider the consumers who are generally best served with the least restrictive requirements.
As I understand it, Tycho will run tests using the configured Java 17 in the tool chain if the project says its test runs on Java 17.
Of course at some point some plugin dependency on which a GEF bundle depends will change its bound to 21 and then only building against an older target platform would allow for actual testing of Java 17 via actual tests. If that happens during the current 2025-03 release cycle, that might require to revisit the decision. And of course another important consideration is what is easiest and the least work for the developers. It's definitely nice to be able to use the latest language features!
On 18.12.2024 12:59, Lars Vogel via gef-dev wrote:
As always I prefer moving to the latest Java if possible. So +1 for moving GEF to Java 21 (for the 2025-03 release).
On Wed, Dec 18, 2024 at 12:21 PM Patrick Ziegler via gef-dev <gef-dev@xxxxxxxxxxx> wrote:
_______________________________________________Hello everyone,
The Eclipse Platform SDK now requires Java 21 due to the dependency to Lucene 10.x which has already led to build problems that could be seen here [1]. The latest GEF-Classic build uses a workaround, to get both the Java 17 and Java 21 builds happy, but even that is no longer possible with recent SimRel changes. In short: We are no longer able to build and test GEF-Classic against Java 17, using the 2025-03 staging repository.
This now also raises the question when we should officially drop support for Java 17. As part of the Simultaneous Release, we are allowed to move to Java 21 since 2024-06, so all formal requirements have already been satisfied. Personally, I would either target the next release (as part of 2025-03) or the release after that (2025-06). Given that we're very early in the release cycle, both options seem valid.
What are your thoughts on this?
Many regards,
Patrick
---
[1] https://github.com/eclipse-gef/gef-classic/pull/628
-------- Forwarded Message --------
Subject: [cross-project-issues-dev] Platform 4.35 I-builds and the Platform SDK Now Require Java 21 Date: Tue, 17 Dec 2024 12:56:52 +0100 From: Ed Merks via cross-project-issues-dev <cross-project-issues-dev@xxxxxxxxxxx> Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> CC: Ed Merks <ed.merks@xxxxxxxxx>
Here are some background details about the Platform's 4.35 (2025-03) development:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2654
___________________________________________
The latest Orbit summary table includes details about the required Java version of each library prompted by Lucene 10's requirement for Java 21 which is first library in Orbit to require Java 21:
https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html
___________________________________________
This is what we're doing to prepare for the eventual Java 24 release:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2623
___________________________________________
Expect a new (minor) version of Guava in Orbit for M1 (or sooner) when this library is approved:
https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/17939
___________________________________________
Happy Holidays!!!!
_______________________________________________
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
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev
--
Eclipse Platform project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev