Code documentation
Development Tools
Code Structure
Techniques and Standards
Help and Web Site
How To
Functional Info
Background Info

JMRI Help:

Contents Index
Glossary FAQ

Donate to

JMRI: Java Version-Specific Features

This page contains information about the compatibility and features of various Java versions. We use this information to decide on our road map for future JMRI versions. (For pre-Java-1.8 content, see the historical page.)

Note: The Java community has moved from a "few big Java releases, years apart" development cycle to a cycle with a new release every six months, and a long-term support (LTS) release every three years. (For background, see here, here, here). For more information on this, see also this Java Magazine article from November 2018 .


This section lists new Java capabilities, and which Java version they first appeared in. The "JDK" column shows the first Java Development Kit that could compile the feature; the "JRE" column lists the first runtime environment that could run the feature, including the needed JVM and library support. Not all updates are included, of course, just the ones that JMRI developers have expressed interest in using or that will cause known problems.

Feature JDK JRE
Multi-version JARs can help with migration from then on, see discussion 9 9
Java Platform Module System 9 9
The Deprecated annotation can take "since" and "forRemoval" specifications, which simplifies our API migration management a lot. 9 8
UTF-8 Properties files (simplifies I18N) 9 9
JLink - improve packaging, faster startup 9 9
Immutable Lists, Sets and Maps: More useful than it maybe sounds, because it can help keep the separate parts (i.e. better and worse code) of JMRI independent. 9 9
var syntax - improves readability of code, use of generics 11 10
Even better support for immutable collections 10 10
Improvements in Optional: or(), ifPresentOrElse() 9 9
More improvements in Optional: orElseThrow() 10 10
Completion of Optional class: isEmpty() 11 11
Improved String whitespace support 11 11
Improved File support, including writeString(), readString(), and isSameFile(). 11 11
asMatchPredicate() method for pattern recognition, which will simplify GUI parsing. 11 11
G1 garbage collector reduces run-time pauses 11 11
TimeUnit conversions provide simplified replacement for deprecated date&time methods. 11 11
var can be used in lambda expressions 11 11
JMRI uses several com.sun classes that will no longer be accessible in Java 16. At some point, we will need to migrate away from these. This can start once we're using Java 11 so that it's done before needed. > 11 > 11
The Z Garbage Collector may provide better performance because of reduced garbage collection pauses. 11 11
A standard installation of GraalVM is available that can run parts of Python 3.7. Although this is "far from complete", no other project appears to be emerging to include Python 3 support in i.e. Jython. Having this available can let JMRI start a gentler migration. 11 11
The Shenandoah garbage collector might be another source of better performance. 12 12
Multiple improvements in the Stream API for ease of use and performance. 12 12
Improved switch statement with more flexible content matching. 12 12
Improvements to the String API: transform, indent 12 12
Record types 14,
improved in 15 and 16
improved in 15 and 16
Improved handling and reporting of NPE, which will help debugging 14 14
The Nashorn interpreter will be removed in Java 15. Some adaptation will be needed to have a JavaScript interpreter, perhaps GraalVM or Rhino. 15 15
More improvements to the String API: formatter, text blocks. 15 15
GraalVM provides "complete" Python 3.7 and JavaScript. At least this version will be required for Nashorn replacement. 16 16
Strong encapsulation by default. 16 16
The module system prevents LibUSB (ch.ntb.usb) from accessing the hardware. This is used in a few scripts. Not clear if its developers will be issuing an update or not; possibly JMRI will have to switch to a different library. 16 16
Objects class has extensions for testing for equality, handling null cases and index manipulation. 16 16
Improved rendering pipeline on macOS which reduces the number of odd display artifacts. First appearance of fully-native JDK on Apple Silicon. 17 17
The RMI activation API is removed, which in some cases will break access for LocoNet Server (not LocoNet Over TCP) connections. 17 17
Java 17 is the next LTS version after Java 11. 17 17
The sun.misc package is replaced by jdk.internal.misc, access to which requires the use of the module system. 18 18
Various elements of the Thread and Locale APIs are marked for deletion, resulting in about 50 compilation warnings. 20 20
JavaDoc improvements: better internal linking, better handling of external packages, code snippets. 20 20
Sequenced collections (replaces existing non-standard workarounds) 21 21
Java 21 is the next LTS version after Java 17. 21 21
(* indicates that a compatibility library is used in the early version)

JRE availability

This section lists the most recent Java Runtime version recommended by Oracle for various operating system versions. Please note that not all users of that operating system will have updated to this Java version; many will be using an older one.

Java installers are now available from multiple sources. Our Java installer page lists a number of them.

JMRI development requires Java 8u101 or later through January 2022. 8u101 contains a certificate change that's needed to link to some remote Javadocs. After January 2022, Java 11 will be required.

Oracle's page on Java 1.7 requirements says "Note: As of April 8, 2014 Microsoft stopped supporting Windows XP and therefore it is no longer a supported platform." Google finds numerous pages that show how to install Java 1.7 on XP or XP SP2. Although the corresponding Java 8 page makes no mention of XP, it seems reasonable to assume the same applies. JMRI's Windows installation page keeps updated information on this. Several JMRI users have reported that Java 1.8_151 is the last one that can be cleanly installed and run on XP. See the Java download archive page for links to that.

Java plans for end of life of various versions:

For more information, see the Java pages for:

Model railroaders may not care if they're using a Java version that's supported. Some of them don't connect their layout computers to the internet; some have single-purpose machines that, if messed up, they'll just reload. But other JMRI users have multi-purpose machines whose security matters; essentially all of the JMRI developers are in this situation. At least some of the developers use dual-purpose machines that are required to meet various security and update standards. For those, Java 8 has increasing become a liability.

Java 11 JDK from Oracle only runs on 64-bit Windows versions (no 32-bit). Adoptium (formerly AdoptOpenJDK) provides 32 bit x86 versions up to Java 19. As of 2024, they continue to provide 64-bit JREs and JDKs. Light red indicates unable to run Java 8 or later; darker red means able to run Java 8, but not Java 11.

OS and platform Last JRE
Linux (depends, but
generally 11+)
Linux Fedora 33 11
Linux Fedora 32 8
Linux Centos 7 11+
Win 11 (64-bit) 11+
Win 10 (64-bit) 22+
Win 10 (32-bit) 19 (Adoptium)
Win 8 (32-bit) 8
Win 7 (32-bit) 8
Win Server 2008 (32-bit) 8
Win Web Server 2008 (32-bit) 1.6
Win 2000 (32-bit) 1.6
Win Server 2003 (32-bit) 1.6
Win 8 (64-bit) 11+
Win Server 2012 (64-bit) 11+
Win Server 2012 R2 (64-bit) 11+
Win 7 (64-bit) 11+
Win Server 2008 R2 (64-bit) 10
Win Server 2008 (64-bit) 1.7
Win Web Server 2008 R2 (64-bit) 1.6
Win Vista (64-bit) 11+
Windows Vista (32-bit) 8
Win 2003 (64-bit) 1.6
Windows XP 8
Windows 98 (2nd Ed) 1.5-11
Windows 98 1.4.2_14
Windows 95 1.3.1_20
Mac OS X 10.10 and later 11+
Mac OS X 10.8.3 Mountain Lion 8
Mac OS X 10.7.3 1.7
Mac OS X 10.5.8 1.6 (Apple JVM)
Mac OS X 10.5.7 and earlier on Intel 1.5 (Apple JVM)
Mac OS X 10.3 and later on PowerPC 1.5 (Apple JVM)
MacOS "Classic" 1.1.8
OS/2 1.3

See the download page for all Operating Systems and
information on Java versions and hardware requirements.

System Requirements

The following combination of JMRI - Java - Platform/OS versions was based on Oracle and OS developers sources. It's translated to the OS install instructions (follow hyperlink in OS headers):

JMRI Java macOS Windows Oracle
Ubuntu Raspbian
5.* 11 10.10 Windows Vista or later
64 bit only
5.5 12.04 14.04LTS
4.* 1.8 10.8.3 Mountain Lion Win7 SP1/8/10, Vista SP2, (XP) 5.5 12.04 14.04LTS
3.10.1 1.7 10.7.3 Lion Win7 SP1/8/10, Vista SP2, (XP) 5.5 12.04 12.04
3.10.1 1.6 10.6 Snow Leopard (JVM6) Win2003, Win2000 (x86) 5.5 10.4 N/A
2.14.1 1.5 10.5.7 Leopard (JVM5) Vista SP1, Win2000 SP3, Win8.x (x64) 9.04 N/A
2.8 1.5 10.4 Tiger Win98 (2nd Ed), XP, ME N/A
2.2 1.5 10.3 Panther Win98, ME N/A N/A N/A
1.3.1 10.3 Panther Win95, Win98 N/A N/A N/A
1.6 1.1.8 MacOS9.1 (MRJ) Win95, Win98 N/A N/A N/A

Running JMRI 5 on Java 17 or later

There are some known problems when running JMRI on Java versions later than the recommended Java 11. Specifically, for JMRI 5 on Java 17 these include:
  1. There is no JavaScript (ECMAscript) interpreter available so .js scripts can't be run within JMRI. Note that this does not affect JavaScript run on a web browser, so that JMRI's webserver capability will still work OK.
  2. The module system prevents LibUSB (ch.ntb.usb) from accessing the hardware. This is used in a few scripts. Not clear if its developers will be issuing an update or not; possibly JMRI will have to switch to a different library.
  3. The Java module system will in certain circumstances emit a large number of "access violation" messages. These are just advisory with Java 17, but will become mandatory failures in some later version of Java (Java 21?)
  4. There's been a problem reported where OpenLCB/LCC network GridConnect connections can't get networking information to create their local Node ID under Java 21. The workaround is to manually enter a node ID in the connection preferences.
  5. (Development only) Improved error checking in the Javadoc process generates hundreds of warnings that can hide real problems. These will need to be cleaned up.
  6. (Development only) Deprecations that are marked for removal generate un-suppressible warning messages. These will need to be cleaned up.