Conversation
Fixes #3770: PerformanceTestProjectSetup hardcoded a stale J2SE-1.5/Java 8 JDT compliance level for its test project. On a modern JDK that EE has no strictly-compatible VM, so JDT falls back to the default JDK 21; java.util.List then exposes getLast() (Java 21 SequencedCollection), Xtend resolves .last to it, and the pinned 1.8 compliance rejects the generated code. The prior emergency fix (#3771) patched the classpath container but left the generated manifest declaring JavaSE-1.8. - Derive JDT compliance from the project's actual JRE container instead of pinning a fixed version (JavaProjectSetupUtil.makeDefaultCompliant), and apply it everywhere the same hardcode-and-drift pattern existed. - Raise the default source/target Java version from 8 to 21 across the generator, standalone builder and IDE preferences, while keeping the ability to compile Java-8-target output for downstream DSLs. - Fix the JavaVersion preference dropdown offering "Java 8" four times (JAVA5/6/7 are deprecated aliases of JAVA8 that don't satisfy isAtLeast(JAVA8), so selecting one silently downgraded codegen). - Introduce JavaVersion.DEFAULT as the single source of truth for Xtext's default Java version, replacing ~15 independent JAVA21/"21"/ "JavaSE-21" literals scattered across the Maven plugins, project wizard, language generator and JDT-facing utilities. Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>
Test Results 8 054 files +4 8 054 suites +4 4h 7m 26s ⏱️ + 29m 32s Results for commit 4104c27. ± Comparison against base commit 40eeb0c. This pull request removes 1 and adds 1 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
CI (run 32637751053) failed identically on all 5 matrix jobs (Linux,
macOS, Windows; JDK 21 and 25) with a single failure:
JvmModelGeneratorTest.testMethodModifiers, at the assertion
Modifier.isStrict(compiled.getMethod("strictFpMethod").getModifiers()).
Since Java 17 (JEP 306, "Restore Always-Strict Floating-Point
Semantics"), javac/ecj no longer emit the ACC_STRICT class file flag for
strictfp members - verified locally: `javac -source 21 -target 21` on a
strictfp method compiles cleanly but Modifier.isStrict() on the result
is false. OnTheFlyJavaCompiler2's default target moved from Java 8 to
JavaVersion.DEFAULT (21) earlier in this branch, so this test's
in-memory compilation now hits that JDK behavior.
Xtend's own code generation is unaffected - JvmModelGenerator still
unconditionally emits the strictfp keyword into the generated source.
Assert that instead of the now-permanently-absent bytecode flag.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3770: PerformanceTestProjectSetup hardcoded a stale J2SE-1.5/Java 8 JDT compliance level for its test project. On a modern JDK that EE has no strictly-compatible VM, so JDT falls back to the default JDK 21; java.util.List then exposes getLast() (Java 21 SequencedCollection), Xtend resolves .last to it, and the pinned 1.8 compliance rejects the generated code. The prior emergency fix (#3771) patched the classpath container but left the generated manifest declaring JavaSE-1.8.