JMRI: Technology Road Map

This 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 Releases

This section describes the (notional) plans for JMRI releases in the future.

Release	Description	Date	JRE	JDK
3.11.*	Development series		1.6	8
4.0	Production version, culmination of 3.11.* series	July 2015 (done)	8	8
4.1.*	Development series		8	8
4.2	Production version, culmination of 4.1.* series	December 2015 (done)	8	8
4.3.*	Development series		8	8
4.4	Production version, culmination of 4.3.* series	Early Summer 2016	8	8
4.5.*	Development series		8	8
4.6	Production version, culmination of 4.5.* series	Late Fall 2016	8	8
4.7.*	Development series		8	8
4.8	Production version, culmination of 4.7.* series	Early Summer 2017	8	8
4.9.*	Development series		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
??	Production version, culmination of Fall 2019 series	December 2019	??	??

JMRI in the Near Future

The 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_72.

The next long-term-support Java release will be Java 11 in Fall of 2018. Oracle intends to align their Java and the OpenJDK at that point. Because some people will need to have that on their computers for other purposes, we intend to 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 our JDK 8 builds on each of the Java 9, 10 and 11 JREs.

You can follow the current status of these on the CI Status page.

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 2019. Allowing for migration and development time, and depending on development plans, JMRI's December 2019 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.18). Releases before Fall 2019 are intended to stay fully compatible Java 8.

It's possible that, as an intermediate step, JMRI development will move to a later Java version without requiring that JMRI users move to a later version. For example, it's remotely possible that JMRI will require Java 11 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.

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.
Our use of JUnit has been partially migrated to the JUnit 4 release, currently 4.12. Among other improvements, this can allow use of the Java assert keyword. We're working on how best to use the new capabilities, see the JMRI JUnit page. At some point, perhaps in 2019, we'll want to migrate to JUnit 5 to get access to new testing tools, particularly for parameterized tests. We also need to complete the conversion from JFCUnit to Jemmy for Swing testing.
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 (our original solution) and SLF4J (the most recent addition). It's likely that we'll eventually simplify that.

Java Release and Operating System Support

More information on Java releases and the operating systems that support them is on a separate page.

Migration Notes

This is a section of notes for various code migrations that are in progress or contemplated.

From JUnit 3 to JUnit 4

JMRI's continuous integration test suites and infrastructure are migrating from JUnit 3 to JUnit 4. For more information, see the section on our JUnit page.

From JDOM 1 to JDOM 2

JMRI 3.11 moved from JDOM version 1 to JDOM version 2. This involved a new jdom-2.0.5.jar file (in place of the earlier jdom.jar), changes to startup and build control files, and some required code changes:

JDOM 2 classes are in the org.jdom2 package instead of org.jdom. This required some changes to import statements and class-references in the source code.
The default output formatting is different, requiring minor changes in e.g. the XmlFile class output routines.

In addition, JDOM 2 uses generics in its input parameters and return values. This means you can remove (now redundant) casts in many places. Jenkins will warn about those.