JME3 Minimum Java Version

A topic of discussion that was brought up on github: JME 3.5.0-alpha1 incompatible with Java 7 · Issue #1661 · jMonkeyEngine/jmonkeyengine · GitHub

What should the minimum supported version of Java be for JME?

My personal thoughts are that it is time to drop support for everything below 8 and make 8 the new minimum for jme 3.5.0.

Java 17 is now the new LTS, and in the long term, we probably need to only support two LTS versions. This keeps us up to date with modern java. For JME 3.6.0, we should probably make 11 the minimum supported version, and work on supporting Java 9 modules.

Just my two cents,
Trevor

7 Likes

I think android has always been the drag.

I’m fine as long as we keep jdk8 compatibility but I thought android required 7 on some level.

2 Likes

Very old versions of android do. New versions can even support jdk 11. I do not think any modern os supports the old versions of Android that required jdk 7.

2 Likes

If Android is not a blocker, any particular reason to maintain jdk8 compatibility? It is EOL this year.

Of note: You can take advantage of parts of the module system, including building a “Minimized” jlinked runtime even if the engine itself is not “Modularized”…

4 Likes

I completely agreed, but it may be good to provide a single release with Java 8 support as the minimum to act as a transition period.

After 3.5.0 is released, I will get a PR together to make jme modular.

4 Likes

Agree with you.

Not anymore. We can use new language features (excluding sealed class) up to Java 17 (including lambda, records, text block, instanceof pattern matching, switch expressions) on old Android versions as well (Android 4.4+) using Android desugaring. I have already tried it.

Edit:
Note that my above statement is only regarding Java Language features.

New Java API features such as Java 11 HttpClient and Java 17 Foreign Function & Memory API is not supported by Android yet. (I have already sent a ticket for Java 11 HttpClient support on the Android issue tracking page and they accepted to support it via desugaring).

4 Likes

My personal thoughts is requiring Java 11 is not something I would like, with the license agreement for Java 11 is not something many people would like to to forced into.

I see Java 17 removed that license and basically went back to no license agreement, I would be more adapt for that version.

Since Java 11, I’ve stuck with Java 8 to avoid the license. I know Java 11 has caused a spawn of the open source and other sources have create a same version of Java 11 to avoid the licensing agreement.

I would think about that, with JME being open source, to tie them to something that is not an open source.

1 Like

You mean the Oracle binary licenses? That is specific to binaries from Oracle. Most of the java world has moved on to other distributions, such as adoptium.net (formerly AdoptOpenJDK) or are building custom JREs direct from OpenJDK source, depending on project priorities.

EDIT: shifted some wording that came out more confrontational than I intended.

4 Likes

To expand on what @sailsman63 said,
Oracle also recently revised their jdk 11 and 17 licencing for organizations that want to use Oracle distributions to be less restrictive. But at this point most people use Adoptium (previously AdoptJDK), which is absolutely free with no license. (Thank you Red Hat, Apache, and IBM)

1 Like

Based on the discussion so far, I’m convinced JME 3.5 should require Java 8 or higher. I’ve removed issue 1661 from the 3.5.0 milestone and labelled it as “wontfix”. I’ve also closed PR 1662.

No need to decide about JME 3.6 right now.

8 Likes

Thank you :slightly_smiling_face: