| Re: [gef-dev] Java 21 for GEF-Classic |
Another point not to be overlooked is that any bundle in the
platform may at any time end up requiring Java 21.
That being said, nothing is impossible. EMF can and does build
against Photon; I just tested and it still works:
Yes, this isn't free; it's extreme. And even though it isn't so
horribly complicated, I'm not suggesting GEF should do that. In
fact, given the limited resource, you should choose the path of
least resistance, the path that's the least amount of work and
lets you use the best new features of the language. If someone
downstream doesn't like that, they should be here helping do the
hard, unpleasant work, not you folk. You're the driver, you
decide how to steer...
Hi,
just to avoid a misunderstanding: The only Platform plugins that currently require Java 21 are:
- org.eclipse.help.base
- org.eclipse.help.ui
- org.eclipse.help.webapp
Which means from a technical perspective, it is still possible to launch e.g. the Eclipse IDE with Java 17 and build RCP applications on top of it, as long as you don't require the online help. But this then comes with a lot of additional caveats, as you e.g. can't simply use the "org.eclipse.platform" feature anymore (as it includes the help) and instead have to cherry-pick all plugins individually. Which is why I believe that this is simply not practical and most projects will pick the easier route and switch to Java 21 as well.
At least from my side, the driving factors for Java 21 is some of the nice API they have added (the SequencedCollection as one of my favorites) and maintainability. As mentioned, the GEF tests require a running Eclipse SDK and it is therefore impossible to automatically test against Java 17 anymore.
So now we are in the unpleasant situation were GEF has to configure additional infrastructure to make sure that we remain compatible with our minimum BREE. Which is of course a lot of extra work that was pushed on us all of a sudden and something was will cause an endless amount of frustration, both on our side and the user side, if not done properly.
Regards,
Patrick
On 21.12.24 21:42, Alois Zoitl via gef-dev wrote:
Hi,_______________________________________________
unfortunately that is not fully true. GEF Classic has several bundles
that require the Eclipse platform. Patrick has this very nicely pointed
out in his previous post.
I also have to disagree on your assessment of Java 21. As a developer
of an RCP using GEF Classic where we already moved to Java 21 I can say
that especially the switch pattern matching makes a lot of code much
easier to read. Especially code in the GEF Classic context.
BR,
Alois
On Sat, 2024-12-21 at 06:28 +0000, Ed Willink via gef-dev wrote:
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 configuredThat's how it's supposed to work but after playing around with it
Java 17 in the tool chain if the project says its test runs on
Java 17.
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 areThat's a fair point. Then perhaps let's approach it from a
generally best served with the least restrictive requirements.
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.ag
gregator/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-aggregat
ion/table.html
___________________________________________
This is what we're doing to prepare for the eventual Java 24
release:
https://github.com/eclipse-platform/eclipse.platform.releng.ag
gregator/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
_______________________________________________
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