Topics

Advancing Java version support (was Re: [jmriusers] Warnings from jogamp when loading JOAL for Audio functions #audio


Bob Jacobsen
 

(N.B. I’ve moved this from Jmriusers as it’s not a user thing. As brief background for people here, the JOAL libraries we support for sound are logging message (a warning with some JREs, error with later ones) due to updates in how Java handles certain kinds of access to internals. The code is fine with JRE8, warns on JRE9, error-but-continue on JRE11, and is likely to break entirely with the next LTS Java release. JMRI asks for Java 8, so this is formally Not Our Problem, but more and more people are going to start encountering things like this as the standard or pre-installed JRE on their computers becomes less and less likely to be Java 8)

The JOAL maintainers have a bug on this that’s a bit interesting to read (although it starts off with a red-herring) as they work through how to handle it via workarounds of various kinds:

https://jogamp.org/bugzilla/show_bug.cgi?id=1317

Their long-term solution is in a (new, not-yet) release of JOAL that has _separate_ Jar files for Java 8 and Java >= 11, without support for 9 or 10.

https://jogamp.org/bugzilla/show_bug.cgi?id=1363
https://jogamp.org
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.4.0

I expect we’ll start to see more and more components like this.

For JMRI, this is one of those boiling-frog cases: Its severity will only slowly increase with time, so it’s hard to know when to do something about it, or what to do at that point.

As a minimum, as we start a new development cycle and maybe a new model:

*) We should try to get/keep the non-Java11-ok things out of our code. Jenkins is building and running with various combinations of Java 11 now, and we might want to upgrade that.

*) We should consider providing a way to start JMRI with different jars and/or command line options depending on the JRE being used. This perhaps could be done in the start-up scripts (although I don’t know enough about NSIS to know what’s reasonable there) for the user downloads, although that might be tricky; It could also be done as different user downloads, if that’s necessary. Not sure how to handle the developer environment in IDEs.

*) We should decide now that Java 9 and 10 (the non-LTS runtime versions) are not supported by JMRI. If it works, great, but if it doesn’t, switch to 8 or 11.

*) At some point, the benefits of moving JMRI to Java 11 will well outweigh the costs (loss of support for some old 32-bit Mac and Windows machines, esp Windows XP, accompanied by much wailing and gnashing of teeth, along with the occasional rended garment) and we’ll have to do it. We might want to set “not before” and “not after” dates for that now, so we can build it into plans arounds Major Releases in the new release model. I.e. (more of an example of a proposal) “not before June 2021, not likely to be after December 2021; bug-fix “update" releases will made for an additional year as possible”. That’ll cause some early unhappiness, but will let people update on their own time line.

Bob

On Jul 9, 2020, at 3:16 AM, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

This line:

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

indicates that only the first illegal reflective access operation will be logged unless the command line option --illegal-access=warn is passed (in the JMRI launchers, it would need to be passed as -J--illegal-access=warn).

Since JMRI supports Java 8, and automatically adding that breaks on Java 8, its not in the JMRI launcher scripts, so you are seeing only the first warning, not all warnings. In 4.19.9, the first warning is about the slider, in 4.21.1, the first warning is about JOAL. I'm sure later versions will have different warnings as we work our way through all these warnings one at a time.

Randall

2020-07-08 11:58:46,154 script.JmriScriptEngineManager INFO - ECMAScript ECMA - 262 Edition 5.1 is provided by Oracle Nashorn 11.0.7 [AWT-EventQueue-0]
2020-07-08 11:58:46,157 script.JmriScriptEngineManager INFO - python 2.7 is provided by jython 2.7.2 [AWT-EventQueue-0]
2020-07-08 11:58:52,175 jython.RunJythonScript INFO - No file selected [AWT-EventQueue-0]
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jogamp.common.os.NativeLibrary$3 (file:/home/andy/Applications/JMRI.4.21.1ish+jenkins+20200706T1618Z+R09904488be/lib/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.jogamp.common.os.NativeLibrary$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
2020-07-08 11:59:32,352 audio.JoalAudioFactory INFO - Initialised JOAL using OpenAL: vendor - OpenAL Community version - 1.1 ALSOFT 1.19.1 [AWT-EventQueue-0]
2020-07-08 12:00:21,828 audio.DefaultAudioManager INFO - Shutting down active AudioFactory [On Start/Stop]




Bob Jacobsen
@BobJacobsen


Randall Wood <rhwood@...>
 

I would like to make either 4.20 or the December 2020 release be the last release that supports Java 8.

I would like from the point where we abandon Java 8, to implement a policy of:
- We support the current and prior LTS releases starting with Java 11 (so when Java 17 is released, we support 11 + 17 and when Java 23 (which I think is the scheduled LTS after 17) is released, we support 17 + 23) and we make a best effort to support two prior LTS releases unless current LTS has an insurmountable incompatibility with the oldest otherwise supported release (i.e. we support 11+17+23 unless there is some incompatibility with supporting 11 and 23)
- We will make a best effort to support only the current non-LTS release, but will not support and other non-LTS releases.

Starting in December 2020, I think that JMRI will either have to risk breaking Jython support (by introducing GraalVM support), drop Java 8 support, or maintain two code bases (a Java 8 codebase and a Java 11+ code base). I’d prefer to just drop Java 8 support. That’s because of planned changes in Java 15+.

I think Java allows us to make JVM-aware JARs (starting with 10?) so we could ship one JAR that loads differently depending on runtime Java version.

Randall

On Jul 9, 2020, at 10:37, Bob Jacobsen <@BobJacobsen> wrote:

(N.B. I’ve moved this from Jmriusers as it’s not a user thing. As brief background for people here, the JOAL libraries we support for sound are logging message (a warning with some JREs, error with later ones) due to updates in how Java handles certain kinds of access to internals. The code is fine with JRE8, warns on JRE9, error-but-continue on JRE11, and is likely to break entirely with the next LTS Java release. JMRI asks for Java 8, so this is formally Not Our Problem, but more and more people are going to start encountering things like this as the standard or pre-installed JRE on their computers becomes less and less likely to be Java 8)

The JOAL maintainers have a bug on this that’s a bit interesting to read (although it starts off with a red-herring) as they work through how to handle it via workarounds of various kinds:

https://jogamp.org/bugzilla/show_bug.cgi?id=1317

Their long-term solution is in a (new, not-yet) release of JOAL that has _separate_ Jar files for Java 8 and Java >= 11, without support for 9 or 10.

https://jogamp.org/bugzilla/show_bug.cgi?id=1363
https://jogamp.org
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.4.0

I expect we’ll start to see more and more components like this.

For JMRI, this is one of those boiling-frog cases: Its severity will only slowly increase with time, so it’s hard to know when to do something about it, or what to do at that point.

As a minimum, as we start a new development cycle and maybe a new model:

*) We should try to get/keep the non-Java11-ok things out of our code. Jenkins is building and running with various combinations of Java 11 now, and we might want to upgrade that.

*) We should consider providing a way to start JMRI with different jars and/or command line options depending on the JRE being used. This perhaps could be done in the start-up scripts (although I don’t know enough about NSIS to know what’s reasonable there) for the user downloads, although that might be tricky; It could also be done as different user downloads, if that’s necessary. Not sure how to handle the developer environment in IDEs.

*) We should decide now that Java 9 and 10 (the non-LTS runtime versions) are not supported by JMRI. If it works, great, but if it doesn’t, switch to 8 or 11.

*) At some point, the benefits of moving JMRI to Java 11 will well outweigh the costs (loss of support for some old 32-bit Mac and Windows machines, esp Windows XP, accompanied by much wailing and gnashing of teeth, along with the occasional rended garment) and we’ll have to do it. We might want to set “not before” and “not after” dates for that now, so we can build it into plans arounds Major Releases in the new release model. I.e. (more of an example of a proposal) “not before June 2021, not likely to be after December 2021; bug-fix “update" releases will made for an additional year as possible”. That’ll cause some early unhappiness, but will let people update on their own time line.

Bob

On Jul 9, 2020, at 3:16 AM, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

This line:

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

indicates that only the first illegal reflective access operation will be logged unless the command line option --illegal-access=warn is passed (in the JMRI launchers, it would need to be passed as -J--illegal-access=warn).

Since JMRI supports Java 8, and automatically adding that breaks on Java 8, its not in the JMRI launcher scripts, so you are seeing only the first warning, not all warnings. In 4.19.9, the first warning is about the slider, in 4.21.1, the first warning is about JOAL. I'm sure later versions will have different warnings as we work our way through all these warnings one at a time.

Randall

2020-07-08 11:58:46,154 script.JmriScriptEngineManager INFO - ECMAScript ECMA - 262 Edition 5.1 is provided by Oracle Nashorn 11.0.7 [AWT-EventQueue-0]
2020-07-08 11:58:46,157 script.JmriScriptEngineManager INFO - python 2.7 is provided by jython 2.7.2 [AWT-EventQueue-0]
2020-07-08 11:58:52,175 jython.RunJythonScript INFO - No file selected [AWT-EventQueue-0]
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jogamp.common.os.NativeLibrary$3 (file:/home/andy/Applications/JMRI.4.21.1ish+jenkins+20200706T1618Z+R09904488be/lib/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.jogamp.common.os.NativeLibrary$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
2020-07-08 11:59:32,352 audio.JoalAudioFactory INFO - Initialised JOAL using OpenAL: vendor - OpenAL Community version - 1.1 ALSOFT 1.19.1 [AWT-EventQueue-0]
2020-07-08 12:00:21,828 audio.DefaultAudioManager INFO - Shutting down active AudioFactory [On Start/Stop]




Bob Jacobsen
@BobJacobsen







Peter Ulvestad
 

I don't really have an opinion (I'm using adopt open JDK 11.xx) but just want to point out that when someone goes to download Java, the main page Oracle sends you to is to download Version 8
https://www.java.com/en/download/

--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/


Randall Wood <rhwood@...>
 

Turns out that on 2020-05-11, Oracle decided to “indefinitely” provide updates to Java 8* with an 18-month warning about when they will stop supporting it.

That changes the picture significantly as previously public updates were going to end on December 2020.**

On Jul 9, 2020, at 15:57, Peter Ulvestad <ulvestad@...> wrote:

I don't really have an opinion (I'm using adopt open JDK 11.xx) but just want to point out that when someone goes to download Java, the main page Oracle sends you to is to download Version 8
https://www.java.com/en/download/

--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/




Randall Wood <rhwood@...>
 

I’ve thought about this some more, and retract my earlier suggestions.

I think we should fully support JMRI only on the current and prior LTS versions of Java (8 and 11 as of now) and make a best effort case to support the current non-LTS version of Java (i.e. if supporting a non-LTS version breaks supporting the current or prior LTS version, we don’t support the non-LTS version).

That would mean only dropping Java 8 support when the next LTS version of Java (currently scheduled to be 17 in September 2021), allowing us to announce our intentions to drop Java 8 support more than one year out (if we announce them now). Provided Oracle sticks to their new LTS release every 3 years timeline, I think this gives us a workable way to telegraph our intentions regarding Java versions well into the future to allow adequate planning time for users to purchase new hardware if needed to use the current version of JMRI.

Randall

On 09-Jul-2020, at 11:16, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

I would like to make either 4.20 or the December 2020 release be the last release that supports Java 8.

I would like from the point where we abandon Java 8, to implement a policy of:
- We support the current and prior LTS releases starting with Java 11 (so when Java 17 is released, we support 11 + 17 and when Java 23 (which I think is the scheduled LTS after 17) is released, we support 17 + 23) and we make a best effort to support two prior LTS releases unless current LTS has an insurmountable incompatibility with the oldest otherwise supported release (i.e. we support 11+17+23 unless there is some incompatibility with supporting 11 and 23)
- We will make a best effort to support only the current non-LTS release, but will not support and other non-LTS releases.

Starting in December 2020, I think that JMRI will either have to risk breaking Jython support (by introducing GraalVM support), drop Java 8 support, or maintain two code bases (a Java 8 codebase and a Java 11+ code base). I’d prefer to just drop Java 8 support. That’s because of planned changes in Java 15+.

I think Java allows us to make JVM-aware JARs (starting with 10?) so we could ship one JAR that loads differently depending on runtime Java version.

Randall
On Jul 9, 2020, at 10:37, Bob Jacobsen <@BobJacobsen> wrote:

(N.B. I’ve moved this from Jmriusers as it’s not a user thing. As brief background for people here, the JOAL libraries we support for sound are logging message (a warning with some JREs, error with later ones) due to updates in how Java handles certain kinds of access to internals. The code is fine with JRE8, warns on JRE9, error-but-continue on JRE11, and is likely to break entirely with the next LTS Java release. JMRI asks for Java 8, so this is formally Not Our Problem, but more and more people are going to start encountering things like this as the standard or pre-installed JRE on their computers becomes less and less likely to be Java 8)

The JOAL maintainers have a bug on this that’s a bit interesting to read (although it starts off with a red-herring) as they work through how to handle it via workarounds of various kinds:

https://jogamp.org/bugzilla/show_bug.cgi?id=1317

Their long-term solution is in a (new, not-yet) release of JOAL that has _separate_ Jar files for Java 8 and Java >= 11, without support for 9 or 10.

https://jogamp.org/bugzilla/show_bug.cgi?id=1363
https://jogamp.org
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.4.0

I expect we’ll start to see more and more components like this.

For JMRI, this is one of those boiling-frog cases: Its severity will only slowly increase with time, so it’s hard to know when to do something about it, or what to do at that point.

As a minimum, as we start a new development cycle and maybe a new model:

*) We should try to get/keep the non-Java11-ok things out of our code. Jenkins is building and running with various combinations of Java 11 now, and we might want to upgrade that.

*) We should consider providing a way to start JMRI with different jars and/or command line options depending on the JRE being used. This perhaps could be done in the start-up scripts (although I don’t know enough about NSIS to know what’s reasonable there) for the user downloads, although that might be tricky; It could also be done as different user downloads, if that’s necessary. Not sure how to handle the developer environment in IDEs.

*) We should decide now that Java 9 and 10 (the non-LTS runtime versions) are not supported by JMRI. If it works, great, but if it doesn’t, switch to 8 or 11.

*) At some point, the benefits of moving JMRI to Java 11 will well outweigh the costs (loss of support for some old 32-bit Mac and Windows machines, esp Windows XP, accompanied by much wailing and gnashing of teeth, along with the occasional rended garment) and we’ll have to do it. We might want to set “not before” and “not after” dates for that now, so we can build it into plans arounds Major Releases in the new release model. I.e. (more of an example of a proposal) “not before June 2021, not likely to be after December 2021; bug-fix “update" releases will made for an additional year as possible”. That’ll cause some early unhappiness, but will let people update on their own time line.

Bob

On Jul 9, 2020, at 3:16 AM, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

This line:

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

indicates that only the first illegal reflective access operation will be logged unless the command line option --illegal-access=warn is passed (in the JMRI launchers, it would need to be passed as -J--illegal-access=warn).

Since JMRI supports Java 8, and automatically adding that breaks on Java 8, its not in the JMRI launcher scripts, so you are seeing only the first warning, not all warnings. In 4.19.9, the first warning is about the slider, in 4.21.1, the first warning is about JOAL. I'm sure later versions will have different warnings as we work our way through all these warnings one at a time.

Randall

2020-07-08 11:58:46,154 script.JmriScriptEngineManager INFO - ECMAScript ECMA - 262 Edition 5.1 is provided by Oracle Nashorn 11.0.7 [AWT-EventQueue-0]
2020-07-08 11:58:46,157 script.JmriScriptEngineManager INFO - python 2.7 is provided by jython 2.7.2 [AWT-EventQueue-0]
2020-07-08 11:58:52,175 jython.RunJythonScript INFO - No file selected [AWT-EventQueue-0]
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jogamp.common.os.NativeLibrary$3 (file:/home/andy/Applications/JMRI.4.21.1ish+jenkins+20200706T1618Z+R09904488be/lib/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.jogamp.common.os.NativeLibrary$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
2020-07-08 11:59:32,352 audio.JoalAudioFactory INFO - Initialised JOAL using OpenAL: vendor - OpenAL Community version - 1.1 ALSOFT 1.19.1 [AWT-EventQueue-0]
2020-07-08 12:00:21,828 audio.DefaultAudioManager INFO - Shutting down active AudioFactory [On Start/Stop]




Bob Jacobsen
@BobJacobsen