Use maven.compiler.release instead of source plus target

[HannesWell]

The use of the --release option of the Java compiler implies a corresponding --source and --target value and is even more powerful: https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html#option-release

[cdietrich]

can you import the reference projects onto xtext dev workspace and execute the launch config to regenerate them.
with that we can verify it works as expected

[cdietrich]

https://github.com/xtext/xtext-reference-projects/blob/master/launch/all-refprojects.launch

[HannesWell]

can you import the reference projects onto xtext dev workspace and execute the launch config to regenerate them. with that we can verify it works as expected
https://github.com/xtext/xtext-reference-projects/blob/master/launch/all-refprojects.launch

Done in

• Regenerate to use maven.compiler.release instead of source plus target xtext/xtext-reference-projects#528

[cdietrich]

thx. wonder how gradle handles these
https://github.com/xtext/xtext-reference-projects/blob/05e0a200617bba171e3be91dcfe10e3bc20bb1fd/greetings-gradle/2.42.0/org.xtext.example.mydsl.parent/build.gradle#L36

[HannesWell]

wonder how gradle handles these

How to admit that I my gradle knowledge is almost zero (tried to use/configure it once and failed miserably).
But since the Maven options map 1:1 on the java compiler options mentioned above, I assume there are some similar options for gradle?

[cdietrich]

how does your schedule next week tuesday at 9am look like?
maybe we should invite you to our Xtext call

[HannesWell]

wonder how gradle handles these

How to admit that I my gradle knowledge is almost zero (tried to use/configure it once and failed miserably). But since the Maven options map 1:1 on the java compiler options mentioned above, I assume there are some similar options for gradle?

According to Gemini AI one can just set

java {
    release = 17
}

Should I apply this too?

how does your schedule next week tuesday at 9am look like?

I could be available.

[cdietrich]

https://github.com/eclipse-xtext/xtext/actions/runs/22051341768/job/63710002939?pr=3603
there seems to be test fail. not sure if related

[cdietrich]

@szarnekow can you add hannes to the meeting

[github-actions]

Test Results

  6 461 files  ±0    6 461 suites  ±0   3h 35m 33s ⏱️ - 1m 26s
 43 236 tests ±0   42 652 ✅ ±0    584 💤 ±0  0 ❌ ±0 
170 059 runs  ±0  167 722 ✅ ±0  2 337 💤 ±0  0 ❌ ±0 

Results for commit dd552a3. ± Comparison against base commit 425a9be.

♻️ This comment has been updated with latest results.

[HannesWell]

https://github.com/eclipse-xtext/xtext/actions/runs/22051341768/job/63710002939?pr=3603 there seems to be test fail. not sure if related

Since it consistently failed over all build I think it is related. The output was

[INFO] --- xtext:2.42.0-SNAPSHOT:generate (generate) @ java-lang-bi-ref ---
[INFO] Encoding: UTF-8
[INFO] Compiler source level: 11
[INFO] Compiler target level: 11
[INFO] Collecting source models.
[INFO] Installing type provider.
[INFO] Generating stubs into /home/jenkins/agent/workspace/xtext_PR-3603/org.eclipse.xtext.maven.plugin/target/local-test-dir/it/generate/java-lang-bi-ref/target/xtext-temp/stubs for 1 resources
[INFO] Compiling stubs located in /home/jenkins/agent/workspace/xtext_PR-3603/org.eclipse.xtext.maven.plugin/target/local-test-dir/it/generate/java-lang-bi-ref/target/xtext-temp/stubs
[INFO] Installing type provider for stubs.
[INFO] Validate and generate.
[INFO] Validating: 'XbaseReferToJava.xbase'
[ERROR] ERROR:JavaRecord cannot be resolved to a type. (file:/home/jenkins/agent/workspace/xtext_PR-3603/org.eclipse.xtext.maven.plugin/target/local-test-dir/it/generate/java-lang-bi-ref/src/XbaseReferToJava.xbase line : 2 column : 5)
[ERROR] ERROR:JavaRecord cannot be resolved. (file:/home/jenkins/agent/workspace/xtext_PR-3603/org.eclipse.xtext.maven.plugin/target/local-test-dir/it/generate/java-lang-bi-ref/src/XbaseReferToJava.xbase line : 2 column : 25)
[WARNING] WARNING:The value of the local variable name is not used (file:/home/jenkins/agent/workspace/xtext_PR-3603/org.eclipse.xtext.maven.plugin/target/local-test-dir/it/generate/java-lang-bi-ref/src/XbaseReferToJava.xbase line : 3 column : 5)

It might be related to the fact that the default source/target version of the xtext/xtend compiler mojo were still at Java-11.
I moved it to 17, which I think makes sense as 17 is the current baseline, doesn't it?

[cdietrich]

yes but i dont remember what @LorenzoBettini did back then when looking into the record topic

[LorenzoBettini]

As I said in #3601 (comment), we need .source and .target because Xtend reads them, but not .release, is that right @szarnekow ?

[cdietrich]

there is

org.eclipse.xtend.maven.AbstractXtendCompilerMojo.javaSourceVersion
org.eclipse.xtext.maven.AbstractXtextGeneratorMojo.compilerSourceLevel

that i could find

[HannesWell]

As I said in #3601 (comment), we need .source and .target because Xtend reads them, but not .release

Indeed, yes that makes sense and explains the error. Thanks! Before this change the mojos read the source/target values from the corresponding properties and now fall back to their default, which is/was Java-11, which doesn't know records.

But I wonder if there is a specific reason to not read maven.compiler.release too and derive the source/target values from it? I can extend this PR and implement it.
For me the only question would be which value takes precedence if all three are set?
As far as I understand the Java compiler doc, release takes precedence over source/target and since the maven-compiler-plugin seems to just translate the parameters to the corresponding compiler flags, I assume it behaves the same.

Then changing the default of source/target/release could be applied in a follow-up (if you want that at all).

[LorenzoBettini]

As I said in #3601 (comment), we need .source and .target because Xtend reads them, but not .release

Indeed, yes that makes sense and explains the error. Thanks! Before this change the mojos read the source/target values from the corresponding properties and now fall back to their default, which is/was Java-11, which doesn't know records.

But I wonder if there is a specific reason to not read maven.compiler.release too and derive the source/target values from it? I can extend this PR and implement it. For me the only question would be which value takes precedence if all three are set? As far as I understand the Java compiler doc, release takes precedence over source/target and since the maven-compiler-plugin seems to just translate the parameters to the corresponding compiler flags, I assume it behaves the same.

Then changing the default of source/target/release could be applied in a follow-up (if you want that at all).

Probably updating the maven plugins to also read that property would be the right way to go.
I'd like to hear from @szarnekow in that respect.

[HannesWell]

Probably updating the maven plugins to also read that property would be the right way to go.
I'd like to hear from @szarnekow in that respect.

Great. I already took action and we can discuss details at

• Support maven.compiler.release parameter in Xtext/Xtend Maven plugins #3607

Since this effectively depends on the latter and it seems Xtext doesn't use SNAPSHOTs of its own Maven plugins it would be good of that could land in the upcoming release