JMRI: Technology Road MapThis page is the road map for JMRI's future development, including changes to our use of Java technologies. It is maintained and updated through continuing discussion on the jmri-developers mailing list.
There's also a page containing the history, particularly the saga of how we moved forward to Java 1.6 and Java 8 across a series of platform-related changes.
JMRI ReleasesThis section describes the (notional) plans for JMRI releases in the future.
|4.0||Production version, culmination of 3.11.* series||July 2015 (done)||8||8|
|4.2||Production version, culmination of 4.1.* series||December 2015 (done)||8||8|
|4.4||Production version, culmination of 4.3.* series||Early Summer 2016||8||8|
|4.6||Production version, culmination of 4.5.* series||Late Fall 2016||8||8|
|4.8||Production version, culmination of 4.7.* series||Early Summer 2017||8||8|
|4.10||Production version, culmination of 4.9.* series||December 2017||8||8|
|4.12||Production version, culmination of 4.11.* series||July 2018||8||8|
|4.14||Production version, culmination of 4.13.* series||December 2018||8||8|
|4.16||Production version, culmination of 4.15.* series||July 2019||8||8|
|4.18||Production version, culmination of Fall 2019 series||December 2019||8||8|
|4.20||Production version, culmination of Spring 2020 series||July 2020||8||8|
|4.22||Production version, culmination of Fall 2020 series||December 2020||8||8|
|(Probably) 5.0||Production version, culmination of Spring 2021 series||June 2021||11||11|
Java and JMRI in the Near FutureThe 4.1.* series of test releases in Fall 2015 started the requirement for Java 8. This has continued through the following release series. Java 8 will continue to be the requirement through at least Fall of 2020. This involves doing development, test and production release builds using Java 1.8.0_181. (We also test on Jenkins with Java 1.8_0_151 to ensure Windows XP compatibility)
The current long-term-support Java release is Java 11 from Fall of 2018. Oracle has aligned their Java and the OpenJDK from that point. Because some people will need to have that on their computers for other purposes, we ensure JMRI can build and run on Oracle Java 8 through 11 and OpenJDK version 11 by using Jenkins to
- Build and run AllTest on each of the JDKs for Java 9, 10, 11; and
- Run allTest from each of those JDK 9, 10 and 11 builds on a Java 8u181 JRE; and
- Run AllTest from our JDK 8 builds on each of the Java 9, 10 and 11 JREs.
At some point, the Java version required by JMRI has to move forward. For example, Oracle has announced that they'll stop providing standalone JRE installers by the end of 2020, by which time JMRI distributions will have to contain the Java runtime components or it won't be possible to run JMRI on newly-bought PCs (will continue to provide independent JREs). That in turn might require tools like jlink from Java 9 or later.
While we don't know with certainty when JMRI development will move past Java 8, we expect that it will be during the Spring 2021 development releases, leading to the June 2021 production releases requiring Java 11 and therefore being called JMRI 5.0. There might be one or two JMRI updates and minor releases early in Spring that would still work with Java 8.
Java Release and Operating System SupportMore information on Java releases and the operating systems that support them is on a separate page.
Migration NotesThis is a section of notes for various code migrations that are in progress or contemplated. These don't directly affect JMRI users in the way that Java version changes do, but they may effect external users of the JMRI libraries.
- At some point, we have to migrate away from JavaHelp and JHelpDev. At a minimum, we'll need to replace the renderer. There are several alternative help systems available. Oracle Help might be a good choice. DocBook as a tool for generating multiple documentation forms is also being considered.
- USB access technology has advanced a lot since support for some basic libraries was added to JMRI. At some point, we should replace those early library versions, but it will break some user scripts.
- Our logging methodology is now a hybrid of native logging (in some included libraries), Log4J 1.2.17 (our logger) and SLF4J (a logging abstraction layer). We may choose to simplify that, but at least we have to move to another logger at some point.