Play Framework

fix: pre-flight Java version check in play CLI (release 1.12.18)

PF-64: `play new myapp --frontend` (and other pre-app-init commands)
surfaced a raw UnsupportedClassVersionError instead of a friendly
"requires Java 25+" message when run on a sub-25 JVM. The framework
jar is compiled for Java 25 (build.xml's build-release=25); CLAUDE.md
states the requirement; but the Python CLI never enforced it before
forking Java.

Three compounding bugs:

1. utils.get_minimal_supported_java_version() returned 17, eight
   majors stale. Anything between 17 and 24 passed the check yet
   still failed at runtime.
2. application.py's existing check printed an ERROR message but
   didn't sys.exit — execution continued, the Java fork happened,
   and the user got both a partial-helpful message AND the cryptic
   class-file-version stack trace.
3. The check was only reachable from app-level commands (play run,
   play test). play new, play deps, and any pre-app-init Java fork
   bypassed it entirely. The user-reported repro path
   (play new myapp --frontend) goes through commands/new.py which
   forks DependenciesManager without ever loading application.py.

Bonus: is_java_version_supported's `except ValueError: return True`
masked parse failures by claiming "supported" — flipped to fail
closed.

Fix:

- utils.py: bump minimum to 25 (with comment that it must match
  build.xml's build-release); flip parse-failure default to False
  and broaden except to AttributeError; harden get_java_version
  against missing java executable (OSError/FileNotFoundError);
  remove the noisy "Unable to retrieve java version" print since
  the new helper handles user-facing messaging in one place; add
  enforce_supported_java_version() helper that does the check,
  prints a multi-line friendly message, and sys.exit(1) on
  failure.
- play (top-level entry): call enforce_supported_java_version()
  immediately after the logo, before any command dispatch or
  filesystem mutation. Catches play new, play deps, and other
  pre-app-init Java forks.
- application.py: route the existing check through the shared
  helper so app-level commands fail-fast consistently and emit
  the same multi-line message.

End-to-end verified on a real Java 21 / Java 25 environment:

  $ /opt/play1/play help    # Java 21 first on PATH
  ~ play! 1.12.18, https://www.playframework.com
  ~ ERROR: Play 1.12.x requires Java 25 or later.
  ~        Detected: Java 21.0.4 at java
  ~        Install JDK 25+ and set JAVA_HOME accordingly, ...
  exit 1

  $ JAVA_HOME=...zulu-25.jdk/Contents/Home /opt/play1/play help
  ~ play! 1.12.18, https://www.playframework.com
  [help output]
  exit 0

The fix runs before any Java fork or filesystem mutation, so
play new no longer leaves a half-created myapp/ directory
when it fails on the version check.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>