A Java mismatch can stop Minecraft before the game window properly opens. PojavLauncher includes different runtimes because Minecraft releases were built against different Java versions. The table below gives you the practical mapping first, then explains what the common class-version error means.
Key points
- Java 8 covers Minecraft 1.8 to 1.16.5, Java 17 covers 1.17 to 1.20.4 and Java 21 covers 1.20.5 upward.
- A newer runtime can read older bytecode, but an older runtime cannot read newer bytecode at all.
- Mod loaders follow the game version, not their own release date.
- Pin the runtime per profile while troubleshooting so automatic detection cannot mislead you.
Why the runtime matters
Java code is compiled to bytecode targeting a particular runtime version. A newer runtime can usually read older bytecode, but an older runtime cannot read newer bytecode at all. That asymmetry is the entire source of the problem.
What the class version error means
An unsupported class version message means the game was compiled for a newer Java release than the runtime you selected. It is not corruption and reinstalling will not help — only switching the runtime will.
Why bundling several runtimes helps
PojavLauncher ships multiple OpenJDK builds precisely because no single one covers every Minecraft version. Keeping all of them installed costs storage but removes an entire class of failure.
The version mapping
This mapping covers effectively every release people still play, and it is worth memorising the three bands.
Java 8 for 1.8 through 1.16.5
The classic band. Most established mod packs, PvP versions and older servers live here, and Java 8 remains the lightest option on constrained hardware.
Java 17 for 1.17 through 1.20.4
The caves and cliffs era onwards. Attempting these on Java 8 produces an immediate class version error.
Java 21 for 1.20.5 and newer
Minecraft 1.20.5 and newer moved to Java 21. For legacy PojavLauncher setups, check the game version against the runtime before changing renderer or memory settings.
- 1.8 – 1.16.5 → OpenJDK 8
- 1.17 – 1.20.4 → OpenJDK 17
- 1.20.5 and later → OpenJDK 21
- Mod loaders follow the game version, not their own release date
Runtime mapping at a glance
| Minecraft version | Required runtime | Symptom if wrong |
|---|---|---|
| 1.8 – 1.16.5 | OpenJDK 8 | Runs on newer runtimes but often performs worse |
| 1.17 – 1.20.4 | OpenJDK 17 | Unsupported class version error on Java 8 |
| 1.20.5 and newer | OpenJDK 21 | Instant crash on Java 8 or 17 |
| Forge or Fabric profile | Follows the game version | Loader fails before the game window opens |
Switching runtimes
Changing runtime is a per-profile setting, so different versions can use different Java releases side by side.
Per-profile selection
Open the profile's settings and choose the runtime explicitly rather than relying on automatic detection when troubleshooting. Automatic selection is usually right, but pinning it removes doubt.
Verifying the change took effect
The launch log states which runtime started. Checking that line saves a lot of second-guessing when a crash persists.
Runtimes and mod loaders
Loaders inherit the game version's requirement, which catches people out when a loader release is newer than the game it targets.
Forge and Fabric both follow the game
A Fabric build for 1.16.5 needs Java 8 even if it was published last month. The game version decides, not the loader's release date.
Mods compiled for newer Java
Occasionally a mod targets a newer runtime than its game version. The mod page will say so, and the fix is to move up a runtime band for that profile only. The mod loader guide covers the rest of the version pairing rules.
Performance differences between runtimes
Newer runtimes bring better garbage collection, but they also use more memory. On a four gigabyte phone, Java 8 with 1.12.2 will usually feel smoother than Java 21 with a current release — not because the runtime is faster, but because the game it runs is lighter. Choose the game version first and let the runtime follow, then tune memory as described in our performance guide.
Diagnosing a runtime problem quickly
Runtime mismatches produce a small family of symptoms. Recognising them saves working through unrelated fixes.
The three symptoms worth memorising
An unsupported class version message means the runtime is too old. A crash before the game window means the loader could not start. A launch that works but performs unusually badly often means an unnecessarily new runtime for an old game version.
Confirm what actually started
The launch log records the runtime in use in its first few lines. Checking that line before changing anything else prevents the common loop of fixing a setting that was never wrong.
Storage, updates and keeping runtimes tidy
Three runtimes sound wasteful on a device with limited storage, but the alternative is reinstalling one every time you change game version.
What the runtimes actually cost
Each OpenJDK build occupies a few hundred megabytes. On a device with several gigabytes free, keeping all three installed is the sensible default; on a 32 GB phone, keep the one your main profile uses and add others when you need them.
When to remove a runtime
Only when storage is genuinely tight, and only for a runtime no profile references. Removing one still in use produces a launch failure that looks like a corrupt install rather than a missing runtime, which wastes time.
After a launcher update
Updates occasionally reset runtime selection to automatic. If a profile that worked yesterday fails today with a class version error, check the runtime setting before assuming the update broke something deeper.
Download reminder: take the build from the project's own repository. The download section on our homepage links straight to it.