Jira is a Java program wearing a web interface. When the Java underneath it changes or disappears, Jira fails faster than it can even write a log - and that speed is your clue.
Some Jira startup failures produce long logs. Java failures produce almost nothing, because if Java cannot start, Jira cannot run - and cannot log. The usual story: someone upgraded the JDK, a Windows cleanup removed an old Java, or JAVA_HOME was changed for another application, and Jira's service now points at a Java that is missing, 32-bit where it should be 64-bit, or simply a version your Jira release does not support. This page shows how to find which Java Jira is really using and set it right.
Jira does not simply use whatever Java Windows prefers. Its startup scripts look at JAVA_HOME first, then JRE_HOME, and the Windows service uses the Java recorded in its own configuration. That is why 'Java is installed' and 'Jira still fails' are both true at the same time - they are talking about different Java installations.
bin folder inside the install directory and find setenv.batJAVA_HOME or JRE_HOME - note the exact folder they namebin folder with java.exe actually exists inside itjava -version from inside its bin folder, and write the version downThis is the step people guess at, and guessing is expensive. Every Jira release supports a specific set of Java versions: older Jira releases run on Java 8 or 11, newer ones require Java 11 or 17, and the newest require Java 17 or later. A Java that is too new fails just as hard as one that is too old - the class-file and module changes are real, not fussiness.
atlassian-jira.logOnce you know the right JDK, make every pointer agree. Changing only the system environment variable is the classic half-fix: the service may keep using the Java stored in its own wrapper settings, and the failure survives your repair.
setenv.bat so JAVA_HOME names the supported JDK folder - no trailing bin, just the JDK rootJAVA_HOME is set therebin folder and confirm the Java path there matchesJava problems have tells. The service fails within seconds. Windows Event Viewer shows the service or JVM erroring before Jira's own logs even begin. And when logs do exist, phrases like UnsupportedClassVersionError (Java too old for the code) or module-access errors (Java too new and strict) name the mismatch directly. A 'Could not create the Java Virtual Machine' message, though, is usually memory settings, not version - that belongs to the heap fix, not this one.
UnsupportedClassVersionError or java.lang errors near the top of the failureThe full Jira startup repair, step by step, with the exact screens and log lines shown live.
▶️ Watch Full VideoBecause Jira probably is not using that Java. Jira follows JAVA_HOME in its own setenv.bat and the Java recorded in its Windows service configuration, which can point to an older or removed JDK while other applications happily use the system Java. Verify the exact java.exe inside the folder Jira points to, with java -version run from that folder.
Only if Atlassian's Supported Platforms page for your exact Jira version lists that Java version. Newer is not automatically supported - a too-new Java breaks Jira just as reliably as a too-old one, through changed class versions and stricter module rules. Match the documented range; do not chase the highest number.
The update likely replaced or removed the JDK that Jira's JAVA_HOME points to, or changed the system JAVA_HOME that another admin later copied into Jira's configuration. The fix is not to roll back the whole server - install or keep a supported JDK side by side and point only Jira at it, using setenv.bat and the service's Java settings.