Re: [gef-dev] Java 21 for GEF-Classic

[Patrick Ziegler <ziegler.patrick@xxxxxxxxxx>]

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