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

[Alois Zoitl <alois.zoitl@xxxxxx>]

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