Versions and editionseasy0-2 years
A tutorial written for Java 8 in 2015 still compiles and runs correctly today. Why does that backward compatibility hold across a decade, and why doesn't "a new Java version every six months" mean constant forced upgrades for a production team?
Java has been strongly backward compatible since 1996 — old code generally still compiles and runs on a new JVM, which is why a 2015 tutorial's code still works even though it's not how anyone writes idiomatic Java today. The six-month cadence (which started with Java 9) doesn't mean six-month upgrades either: most releases in between are supported only until the next one arrives, but a handful are designated long-term support (LTS) — 8, 11, 17, 21, 25 — and get years of security patches. Production teams sit on an LTS and move between LTS releases roughly every two years, not every six months; the frequent releases are where new features show up early, on something that isn't paying anyone's salary yet.
Previous`java -version` reports 21. `javac -version` reports 17. The build fails with errors about syntax that is definitely valid Java 17 and definitely legal in 21. What's actually going on, and why are `PATH` and `JAVA_HOME` both part of the answer?Next You see three different errors on three different days: `Greet.java:3: error: ';' expected`, `Error: Could not find or load main class Greet`, and a stack trace ending in `ArrayIndexOutOfBoundsException`. How do you tell what kind of problem each one is from the shape of the message alone, and why does the middle one confuse people the most?