Java 21 Masterplan

[cdietrich]

Once Java 21 LTS is out we should try to support it

• set minimum supported version to Java 17, Drop Java 11 (build)
• adapt JavaVersion Enum
• adapt Wizard test
• asm version?
• adapt platform dependencies in dev-bom
• adapt minimal target platform
• adapt gradle version in wizard
• check if classgraph needs adaptation?
• check if tycho needs adaptation?
• Guice/Guava update needed?
• new MWE?
• check java version switches in tests
• new Jetty version needed?
• with new minimal target version, check which reflective switches we can get rid of (platform, jdt)
• deal with Java deprecations

TODO: 100 things i have forgot

[cdietrich]

Guice and Guava is now on latest. we will see if this is sufficient

[OLibutzki]

As Java 21 has been released today, do you have any roadmap when to support it? Especially solving the jdt issue mentioned in #2680 is something we are looking forward to.

[cdietrich]

There is no road map and as Xtext is no longer my day job it might take long. First question: are Java 21 capable eclipse platform and jdt maven artifacts already available or will they ship in December ?

[OLibutzki]

Hmm, this issue is "open", no new comments for months.

eclipse-jdt/eclipse.jdt.core#890

[cdietrich]

https://github.com/eclipse-jdt/eclipse.jdt.core/commits/BETA_JAVA21 Shows some wip

[mpalat]

Please see : https://www.eclipse.org/lists/eclipse-dev/msg12203.html

[cdietrich]

with https://www.eclipse.org/lists/eclipse-dev/msg12207.html we wont have maven artifacts before end of year.
am not sure if there are maven snapshots meanwhile so development can start before

[DanySK]

Hi, is there any update on this plan?

I guess that errors like org.eclipse.xtext.common.types.access.TypeResource$CannotLoadTypeResourceException: java.lang.IllegalArgumentException: Unsupported class file major version 65 are due to Xtext not yet supporting Java 21 - am I correct?

I am asking because this is preventing Protelis from becoming Java 21 compliant which, in turn, also prevents Java 21 compliance for the Alchemist Simulator.

[cdietrich]

No jdt java 21 maven artifacts no java 21 in Xtext

[cdietrich]

Besides that: when these become available this is a help wanted story

[gmlongo1]

Has there been any progress on this? We make excessive use of generators in our daily builds and are looking to move to Java 21 in the very near future.

[cdietrich]

Obviously no. And Xtext is no longer my day job. And nobody seems to step in

[gmlongo1]

Not sure why "obviously" was needed, as its been 4+ months so we were just looking for any feedback. Are we saying xtext is no longer being officially maintained? If there is no roadmap for Java 21+, those of us that heavily rely on xtext will have to make plans to move away from the tool.

[cdietrich]

#1721

I don’t think I alone can do this in my spare time while working at a startup

maybe you want to step in and contribute

[gmlongo1]

I completely understand the lack of time due to other commitments. We will need to react accordingly.

[LorenzoBettini]

This doesn't mean that Xtext is no longer officially maintained (see the number of commits in the last few months).

However, IIRC, if you don't use records from within xtend you shouldn't have problems switching to Java 21, or am I missing something?

[gmlongo1]

When I switch to Java 21 from 17, I start getting "cannot resolve proxy: java:/objects/java.lang.string#java.lang.string" errors. No other changes to the code other than changing the version of Java.

[cdietrich]

The old jdt dependencies and the Java version Enum don’t support Java 21
So it wound work with source and target 21

@gmlongo1 which usecase are you executing maven gradle eclipse tycho ant ?

[DanySK]

@LorenzoBettini nope, Xtext is failing with Java 21. It does not build with Java 21 (see: Protelis/Protelis-Parser#345), and code produced with previous Java versions fails at runtime when running Java 21, see: https://scans.gradle.com/s/l4r2lg34vs5cu

DiagnosticWrappedException: org.eclipse.xtext.common.types.access.TypeResource$CannotLoadTypeResourceException: java.lang.IllegalArgumentException: Unsupported class file major version 65

[HannesWell]

DiagnosticWrappedException: org.eclipse.xtext.common.types.access.TypeResource$CannotLoadTypeResourceException: java.lang.IllegalArgumentException: Unsupported class file major version 65

Can you provide a full Stack-Trace for that?
Maybe ASM needs an update.

[LorenzoBettini]

The old jdt dependencies and the Java version Enum don’t support Java 21 So it wound work with source and target 21

The old jdt dependencies are the maven ones, right? Because in the TP we already use the latest ones, don't we?

[cdietrich]

Yes the maven ones . In the target it depends in which and what you select in the wizard

[DanySK]

@HannesWell
I did, can you access the gradle build scan? https://scans.gradle.com/s/l4r2lg34vs5cu

Here's how to reproduce:

1. git clone https://github.com/Protelis/Protelis.git
2. cd Protelis
3. git checkout renovate/org.danilopianini.multi-jvm-test-plugin-0.5.x
4. ./gradlew testWithJvm21

It should "fail correctly" with any major OS and regardless of the JVM you use to run Gradle.

[HannesWell]

I did, can you access the gradle build scan? https://scans.gradle.com/s/l4r2lg34vs5cu

Sorry I oversaw that, but looking at it now I fail to see the root cause.

I haven't checked-out your project, but I run all our xbase-based DSL with Java-21 as well as my developer eclipse (also executed mwe workflows) and didn't notice any issues with it.

The only thing I noticed so far(there might be more not yet uncovered) is that the xtend-Maven-plugin has a literal for Java-21 missing in the JavaVersions class.
I can provide a PR to add that.

[cdietrich]

as elaborated before

• enum needs adaptation
• jdt and platform dependencies need bump
• this also requires java 11 drop

[DanySK]

@HannesWell I fixed it by constraining the ASM version manually like this: Protelis/Protelis@c78854f

[cdietrich]

@shankar-itemis but why is having an annotation in general and com.google.inject.Inject bad. of course we have a billion of these

[shankar-itemis]

@cdietrich Its not bad. As you know the javax.inject has to be migrated to jakarta.inject in java 21. So as part of JDK 21 analysis this was done.

Although guice abstracts this dependency and implement JSR-330 completely, the Provider of guice extends JSR 330. https://github.com/google/guice/wiki/JSR330. And from guice 7.0 it only supports jakarta.inject and not java.inject. So I was just ensuring that.

[cdietrich]

i still dont dont understand.
to my knowledge we dont use javax.inject anymore

[shankar-itemis]

@cdietrich To my understaing the guice provider was extending javax.inject. This was an implicit dependency that guice had with javax.inject and I was in search of that.

Pls correct me if I my understanding is wrong here.

[cdietrich]

And from guice 7.0 it only supports jakarta.inject and not java.inject. So I was just ensuring that.

but this would mean they change their code
so i dont understnad why the guice inject class should be bad

[szarnekow]

It isn't bad and neither is a use of an annotation bad.
I think the ongoing analysis is based on bogus assumptions.

The code-base can be grep'ed easily for javax.inject or com.google.inject to find usages.

For Xtext, we decided to use exclusively com.google.inject types to configure the dependency injection container. That won't change.

[shankar-itemis]

I would like to clarify that neither the annotations or guice inject are bad. I was just analysing the places where annotations were made use and was there some direct references to javax.inject.

sorry if i have confused you on this. @cdietrich

[szarnekow]

@shankar-itemis thank's for the analysis and for sharing the code.

The gained information is unfortunately not providing any actionable insights, since annotations are commonly used in Xtext and processing all of them in an untargeted fashion is not helpful.

[LorenzoBettini]

As noted here #2823 (comment) at least from Eclipse with JDT access to Java 21 records seems to work out of the box from Xtend. I tested it manually. @szarnekow any hint on how to place a test in some of the existing test projects?

Then, I guess we need to adapt the standalone part, including the upgrade of JDT in the BOM. To test that, would it be enough to use the tests in our maven plugin projects? Or are there better places to test that?

Such experiments are in my fork https://github.com/LorenzoBettini/xtext/tree/lb_java_21-2

While #2986 could already be merged

[szarnekow]

@szarnekow any hint on how to place a test in some of the existing test projects?

I'd guard the test with a check that we have a Java21 available.
If so, use a record type from the JDK from Xtend source or put a Java record source file into an Xtend test projects side by side.

[LorenzoBettini]

@szarnekow OK, but does something like this LorenzoBettini@3059e10 make sense, or is it useless?

[szarnekow]

I think it does make sense, but we should also have a test that uses a Java record from Xbase (can be an Xtend integration test).

[LorenzoBettini]

@szarnekow yes, I just wanted to start from the bottom and then up ;)

[LorenzoBettini]

Some nice updates:

• added a compilation test for Xbase accessing Java record LorenzoBettini@c2befaf @szarnekow I haven't found a record in the JDK, unless I miss something, there's only a record about some Unix stuff, so I used draw2d that's already in our TP; I could add one also in Xtend but having in Xbase should be enough, shoudln't it? In Xtend, I'm planning to a add a validation test trying to extend a record, which is detected as final; by debugging, I found that a record is automatically considered final
• then a test for standalone builder LorenzoBettini@ffac152
• last, but not least, an xtext-maven-plugin test for an Xbase language LorenzoBettini@21b24ac note that I had to force a more recent version of JDT supporting Java 21 in the plugin configuration in the IT project; without the updated JDT version the test fails as expected

The next step would be to update our dev BOM with the new JDT code. This will require Java 17 as the minimal version, unless we set the profile in the BOM switching the JDT version according to the current Java, as I had experimented here https://github.com/LorenzoBettini/maven-bom-profiles-example

[szarnekow]

This will require Java 17 as the minimal version

If by any means possible, I’d like to have Xtext 2.35 released with Java 11 bytecode. If that contradicts the ability to consume Java 21 bytecode, that would be very sad.

[LorenzoBettini]

@szarnekow there's no need to switch to Java 17 as requirement, and we can still ship Java 11, if we want to.

My experiments are meant to be sure we can consume Java 21 stuff (if we can consume records we should be safe in that respect).

Mostly, there are tests in my fork's branch.
The only real change in the code base is this one LorenzoBettini@45519f5 but that method has been available for a while and should work also with our current JDT versions.

In Eclipse, as long as one uses the latest JDT there's no problem accessing Java records.

Concerning Maven, if we don't want to update the BOM, it is enough to document to add the more recent JDT as explicit dependencies LorenzoBettini@21b24ac#diff-88e2b37f635d0790f54a2d314a7b4cb75652b846440f6d878a709a5a7910baadR55 if one want to access Java records.

To make Maven users easier, we could use the profile "trick" in the BOM I mentioned above. In my experiment, I switch to an older version of JDT when the current JDK is not Java 17 https://github.com/LorenzoBettini/maven-bom-profiles-example/blob/master/bom-example/pom.xml#L28. But of course we could do the opposite: switch to a newer version of jdt if the current JDK is at least Java 21 ;)

[cdietrich]

unfortunately i dont find the time to experiment with gradle and maven

[LorenzoBettini]

@szarnekow @cdietrich some updates:

• I applied the profile in the BOM, automatically activated when using Java 21, switching to the recent version of JDT core and it works: the xtext-maven-plugin test now works without explicit jdt dependencies: LorenzoBettini@3e7d608 Thus, for previous versions of Java nothing changes and we can keep producing Java 11 bytecode
• I added an xtend-maven-plugin test that also works: LorenzoBettini@315cbe8
• Finally, I added an Xtend validation test that correctly detects a record as a final class: LorenzoBettini@6026fd4

Concerning gradle, if it doesn't pick the Maven profile correctly, it's just a matter of forcing a more recent version of jdt.core in the xtend-maven-plugin configuration

[cdietrich]

the problem is gradle does not use the xtend-maven-plugin.
but its own.
there is also the xbase usecase.
dont know if and how this affects the xtext-maven-plugin

[LorenzoBettini]

the problem is gradle does not use the xtend-maven-plugin. but its own.

then, the updated jdt core versions should be specified there

there is also the xbase usecase. dont know if and how this affects the xtext-maven-plugin

please, see my comments above: I added tests in that respect, both for xtext-maven-plugin and xtend-maven-plugin

[cdietrich]

so you propose doing the override in the gradle wizard and write a "what to do in xbase case" guide for gradle

[LorenzoBettini]

so you propose doing the override in the gradle wizard and write a "what to do in xbase case" guide for gradle

Yes, that would be a good strategy!

[cdietrich]

but the experience shows this is very very very very very error prone

[LorenzoBettini]

That's the best we can do. In the worst case, gradle users will not be able to use Java 21, which is the current state anyway. For the rest, nothing will be broken.

[cdietrich]

yeah but then we need an error / warning in the wizard etc...

thus my preference regarding sebastians proposal:

• keep java 11 for 2.35
• ditch it for 2.36

[LorenzoBettini]

Please see my comments above. My proposed solution would allow us to keep Java 11 while still providing support for Java 21 for those who want to move to Java 21.