fix: write the Java version in the dialect the stored key expects

[ako]

Fixes the red nightly. This is a regression from the mendixlabs#759 fix (PR #78).

The bug

mendixlabs#759 handled the property rename — Mendix renamed JavaVersion to JavaMajorVersion between 11.6 and 11.12 — but wrote the caller's value through verbatim. The rename changed the value format as well: 11.6 stores the enum member "Java21", 11.12 the bare major "21".

So alter settings model JavaVersion = 'Java21' on an 11.12 project put "Java21" into JavaMajorVersion, and mxbuild refuses to load the project at all:

ERROR: System.ArgumentOutOfRangeException: Specified argument was out of the range
of valid values. (Parameter 'majorVersion is an unsupported value: Java21')
   at Mendix.Modeler.Settings.JavaVersionExtensions.fromString(String majorVersion)
   at Mendix.Modeler.Settings.RuntimeSettings.get_JavaVersion()

mdl-examples/doctype-tests/14-project-settings-examples.mdl:40 does exactly that, which is why the nightly went red on all three Mendix versions and both engines.

Worth noting the failure mode is sharper than the original mendixlabs#759 shape. That one wrote an unknown property, which mxbuild tolerates — only Studio Pro broke, so it took a user report to find. A wrong value for a known enum fails the whole project load, taking every check downstream of the settings unit with it.

The fix

settingsoverlay.JavaVersionValue renders the value in the dialect the stored key expects — strip the Java prefix for JavaMajorVersion, add it for JavaVersion. Either spelling is accepted on input and stored in the project's own dialect, so one MDL statement is portable across versions. A value with no recognisable major version passes through untouched, so a typo surfaces as a Mendix error rather than as a silently mangled setting.

The overlay is shared by both write engines, so the codec and legacy paths are fixed together.

Verification

Against real projects with mx check (11.12.2 and 11.6.6 mxbuild):

Project	Input	Stored	mx check
11.12.2, pre-fix binary	'Java21'	Java21	ArgumentOutOfRangeException — the nightly error, exactly
11.12.2, codec engine	'Java21'	21	0 errors
11.12.2, legacy engine	'Java21'	21	0 errors
11.6.6, codec engine	'21'	Java21	0 errors

Unit tests at both layers — TestJavaVersionValue_MatchesKeyDialect / TestSetJavaVersion_ConvertsToStoredDialect on the overlay, TestUpdateProjectSettings_JavaVersionValueMatchesKey on the backend write. Mutation-checked: reverting SetJavaVersion to the pass-through fails all four backend cases and the overlay test.

Also in this PR

• Docs corrected. The mendix/project-settings skill and the docs-site page disagreed — the skill showed 'Java21', the site '17'. Both work now, and both pages state the dialect rule.
• Repro fixture mdl-examples/bug-tests/759-java-version-value-dialect.mdl, and a symptom-table row in fix-issue.md.
• One out-of-scope line. modelsdk/mpr/serialize_services.go carries a dead third copy of this write with no callers; its raw["JavaVersion"] = ... line now goes through the same helper so wiring it up later cannot reintroduce the bug. The rest of that file is an unreviewed port that still rebuilds configurations from the model — left alone.

🤖 Generated with Claude Code

https://claude.ai/code/session_012XR649rKk68z6gBpngu6MA

---

Generated by Claude Code