claude-code - 💡(How to fix) Fix [FEATURE] Cloud environment: add Java 25 (JDK 25) support [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The Claude Code cloud environment ships with Java 21 (21.0.10+7-Ubuntu-124.04). Projects targeting Java 25 via Gradle's toolchain management fail because JDK 25 is not installed and Gradle's toolchain auto-provisioning cannot download it due to network restrictions (403 from adoption API).

Execution failed for task ':kinotic-core:generateEffectiveLombokConfig'.

Cannot find a Java installation on your machine (Linux 6.18.5 amd64) matching: {languageVersion=25, vendor=any vendor, implementation=vendor-specific} Toolchain download repositories have not been configured.

This blocks Claude from compiling, running tests, or validating code against the project's actual target JDK. Java 25 reached GA in March 2025 and is increasingly adopted — Spring Boot 4.x and other major frameworks now target it.

Proposed Solution

Install JDK 25 (e.g., Eclipse Temurin 25) alongside JDK 21 in the cloud environment. Gradle and Maven toolchain management will auto-detect installed JDKs, so no configuration changes are needed — just having it on disk is sufficient.

Ideally, keep the environment current with GA JDK releases (a new one ships every 6 months). Having at least the two most recent LTS versions plus the latest GA release would cover the vast majority of Java projects.

Alternative Solutions

Allow toolchain auto-provisioning network access: Whitelist api.adoptium.net and download.java.net so Gradle/Maven can download JDKs on demand. This is more flexible but adds download time to every fresh session.

Support a session startup hook for custom JDK installation: Let users define a setup script (e.g., via sdkman or direct download) that runs before Claude starts working. This is the most flexible but pushes the burden onto every user who needs a non-default JDK.

Current workaround (not ideal): Override the toolchain version via environment variable to fall back to Java 21. This compiles the code but doesn't validate against the actual target JDK — Java 25 language features and API usage errors would go undetected.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

We're building a Spring Boot platform (kinotic-ai/kinotic) that targets Java 25. Our Gradle build uses toolchain management:

java { sourceCompatibility = '25' toolchain { languageVersion = JavaLanguageVersion.of(25) } }

When Claude Code attempts to compile the project in the cloud environment, it fails immediately at the toolchain resolution step. Claude cannot verify that any code it writes actually compiles, which undermines the core value of having an agentic coding assistant — the feedback loop is broken.

To work around this, we had to add a configurable override to our build:

def toolchainVersion = Integer.parseInt(System.getenv('JAVA_TOOLCHAIN_VERSION') ?: '25')

This lets Claude build with Java 21, but it means Java 25 features like flexible constructor bodies, module imports, and compact source files would silently compile under 21 and then fail in CI/production. It also means Claude can't catch API differences between 21 and 25.

Additional Context

• The cloud environment also blocks access to the Gradle Plugin Portal (plugins.gradle.org returns 403 for some artifact URLs), which prevents resolving plugins not already cached. We worked around this separately by making plugin dependencies conditional, but it compounds the friction for Java projects.

• This likely affects any Java project targeting JDK 22, 23, 24, or 25 — not just ours. The six-month JDK release cadence means the environment will fall further behind over time without a plan to keep it current.

• Maven projects using maven-toolchains-plugin or <release>25</release> would hit the same issue.