Compilation error when using var in Java submissions on LeetCode

The short answer

Your code is probably fine — the compiler is not. LeetCode's Java environment compiles submissions at the Java 8 language level, and var (local-variable type inference) was only introduced in Java 10. The same applies to switch expressions (Java 12+, standardized in 14) and the java.net.http.HttpClient API (Java 11). There is currently no user-facing setting to select a newer JDK, and no officially announced upgrade timeline, so the only reliable fix inside LeetCode is to write Java 8-compatible code.

Confirmed facts vs. likely explanation

Confirmed: var is a Java 10 language feature. A compiler running with source level 1.8 will reject it, typically with cannot find symbol (it parses var as an identifier) or an explicit source version 1.8 style error. LeetCode's own FAQ documents a JDK 8 baseline for Java submissions.

Likely, but worth verifying: The exact error text you see depends on where var appears. If the message mentions cannot find symbol: class var, that's the classic Java 8 signature. If it mentions source/target versions, the platform is telling you the language level directly. Either way, the root cause is the same.

Answers to your three questions

1. Can you select a newer Java version? No. LeetCode does not expose a JDK or language-level selector for Java submissions. Compiler flags like --release 11 cannot be injected through the submission interface.
2. Is there an announced upgrade roadmap? As of this writing, no public timeline has been announced. Treat the JDK 8 baseline as the stable contract and check LeetCode's FAQ or release notes periodically — this is the one detail that could change and would invalidate this answer.
3. Workarounds? Only syntactic ones, inside the platform.

Practical rewrites that compile on JDK 8

// var (Java 10+) -> explicit type
var map = new HashMap<String, Integer>();
// becomes
Map<String, Integer> map = new HashMap<>();

// switch expression (Java 14) -> classic switch
int n = switch (x) { case 1 -> 10; default -> 0; };
// becomes
int n;
switch (x) {
    case 1: n = 10; break;
    default: n = 0;
}

Note that the diamond operator <> is fine — it's Java 7. Most LeetCode solutions lose very little by using explicit types; var is largely a readability convenience.

How to verify before blaming the platform

Reproduce locally to confirm the feature itself works and the failure is environmental:

javac --release 8  Solution.java   # should fail on var, matching LeetCode
javac --release 11 Solution.java   # should compile

If the Java 11 build succeeds, your logic and syntax are correct and the LeetCode error is purely the JDK 8 target. If you want to practice modern Java idioms, use a local JDK or another online judge that advertises a newer Java version, then backport to Java 8 syntax when submitting to LeetCode.

Bottom line

There is no switch to flip. Until LeetCode upgrades its Java toolchain — which it has not committed to — restrict submissions to Java 8 syntax: explicit type declarations, traditional switch statements, and no post-8 standard-library APIs like HttpClient.