Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Java 21 for GEF-Classic

Hi

Yes. The outer (Tycho) JVM will have to be Java 21.

But No, The inner (test) JVM can be overridden by the maven-toolchains-plugin.

For OCL I was 'happily' running Java 5 compatibility testing until the EF discontinued the Java 5 support on Jenkins. Java 8 compatibility testing could not handle builds by the latest Java 18 signing algorithm. But Java 11 testing is still possible with Tycho on Jenkins.

Since GEF provides diverse capabilities that can be used without the IDE, I feel that the BREE should be as low as feasible.

(Personally I do not find the latest Java features useful since sadly the debugging support is deficient; single stepping by 'lines' cannot work when a single line has multiple partial occluded constructs.)

Regards

Ed Willink

On 20/12/2024 20:40, Patrick Ziegler via gef-dev wrote:

> 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.


On 18.12.24 14:09, Ed Merks via gef-dev wrote:

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

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev

Virus-free.www.avast.com

Back to the top