JMRI: Technology Road MapThis page is the road map for JMRI's future develpoment, 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|
|??||Production version, culmination of Spring 2020 series||July 2020||??||??|
JMRI in the Near FutureThe 4.1.* series of test releases in Fall 2015 started the requirement for Java 8, also known as Java 8. This has continued through the following release series. The December 2018 release, notionally JMRI 4.14 will remain with Java 8, but may involve other library updates. This includes 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. That in turn might require tools like jlink from Java 9 or later.
While we don't know yet when JMRI will have to move past Java 8, we do know that the earliest Java 9 or later will be required for users is Fall 2020. Allowing for migration and development time, and depending on development plans, JMRI's December 2020 release might require Java 11 (in which case it would be called JMRI 5.1) or stay with requiring Java 8 or later (in which case it would be called JMRI 4.20). Releases before Fall 202 are intended to stay fully compatible Java 8.
It's possible that, as an intermediate step, JMRI development will move to a later Java SDK version without requiring that JMRI users move to a later Java JRE version. For example, it's remotely possible that JMRI will require a Java 11 SDK to compile and build distributions, which would still be able to work on Java 8. We prefer to do that to keep older hardware working, but it's not always possible. (Note: Here, we're talking about using the Java 11 SDK, not about using Java 11 language features. Java 9 through 11 SDKs require setting their source version and runtime version to the same value; you can't compile i.e. Java 11 source code for a Java 8 runtime)
There are also smaller migration issues. 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.15 (our original solution) and SLF4J (the most recent addition). We may choose to simplify that, but at least we have to move to Log4J 2 at some point.