JDK 11 Build Support

This is a really important design question.
Should we/can we really need to support backward compatibility with java 7 while being able to use java 8, 11, … ?
If answer is yes, then there is no other way than using the maven artifact for any module that is removed in java 8, 11,…

And I think first we need to answer this question, then we can decide which path we should go.

And some experienced person like @pspeed can be the right guy to answer this question.

I am not qualified to answer it, but for me, it is not important to keep with java 7. (I had lived with java 7 only for a few months when I first started programming then soon Java 8 came and I switched to it and now I am on 11) . So I am totally ok with giving up on java 7.

This brings up a whole new dimension: using java 8 and then only have new code use java 8 is odd in terms of consistency. But we also can’t refactor everything to java 8, but at least we could fix all the diamond operators.

If by this you mean:

List<Foo> foo = new List<Foo>();

Gets converted to:

List<Foo> foo = new List<>();

This has always been supported in JDK7. It wasn’t in JDK6. Any code you see like that is fine to convert even if we don’t move to JDK8.

I feel like dropping JDK7 support is essentially cutting off a large swath of Android support. I don’t use it so I don’t “have a dog in that fight”… but I know others do and might miss being able to use JME for their projects. “But but… the latest phones will work just fine maybe with some tweaks and stuff because we haven’t tested it…” Even so, that cuts off a LOT of potential customers in a market that is already going to be small enough.

Personally, I don’t see a strong reason to move to JDK11 with any urgency. It’s really a shame that Java is getting messed up in totally incompatible ways. It had a long run, though. Given relative time scales, it could be that some monkey makes JME4 before it becomes an urgent problem.

Another thing to consider is that if someone wants to use JDK 7, JME 3.2.x still works just fine. It is not like this kills off all other JME3 versions.


For what it’s worth my Android games have worked fine using Java 8 and JME.


@BigBob, would you be willing to test the JKD-11 branch built using JDK8 to let us know if it works for you?

1 Like

Yep, I have also been using Java 8 with the SDK and android.
Works great.

1 Like

It’s very good news.

I am curious to know if anyone has a test JME gradle project setup for android ?

Ehm, I think I found one:

But as I have never worked with android before, I do not know how should I use it, so is anyone willing to give it a try using JDK-11 branch built using JDK8 here :

This was a good opportunity for me to learn and test android using above gradle template.

I locally compiled jdk-11 branch with Java 8 and created a hello world (blue cube) example apk and I was able to run it on my phone with android 4.0.3 successfully.

I used following tutorial to install android sdk on linux (No need to install Android Studio at all) :

Then I set sdk path in

also changed this line :

to :

classpath 'com.android.tools.build:gradle:3.3.2'

and commented out this line:

    // We do not need this, as each version of the Android Gradle Plugin now has a default version of the build tools.
    //buildToolsVersion "24.0.2"

btw, we can compile it even with java 11 (with no need to have java 8 installed), we just need to set “–release 8” flag to java compiler in gradle build. (I have not tested this myself yet)

compileJava {
  options.compilerArgs.addAll(['--release', '8')]

see this for more info:

Edit 2:
Forgot this one, I also add





I’m using JDK8 with JME and Android. It is working perfectly so far.


Thanks guys, new PR is tested successfully on Linux, Android, Windows.
We will appreciate if someone can test it on Mac too :slightly_smiling_face:


The problem I see with JDK11 is not current compatibility. Rather, it is the new Oracle phylosophy to break stuff every 6 months, which means that we won’t be able to keep up and will fragment the community until death.


The major breaks the happened in jdk 9-11 we’re a Java cleanup of sorts. They we’re removing all of the old build tools and finished separating javaee from se. And although it causes a lot of growing pains, it will make the environment cleaner moving forward.

My understanding is that the only large change that came out in jdk12 is the disability to use reflection under what we consider normal circumstances. It is still possible, but will require modules to be fully implemented. Perhaps someone here might know more about that?

1 Like

Thanks, millennial* hipsters and Angular team! (Yeah, I’m just going to guess that the trendy 6 month Angular release cycle had something to do with that.)

*sorry to any millennials here with common sense

Has anyone had a chance to test this branch on OS X. I would love to get this merged in.

Even if no one had a chance to test it with OSx I think yet we are fine to merge it as it is going to appear on alpha release anyway, so people will have better chance to test it on 3.3.0-alpha2. :slightly_smiling_face:


What exactly needs to be tested on OSX? Just compiling with JDK11?

Yep, just compiling and perhaps running a test to make sure it still loads.

EDIT: @Ali_RS I agree, there is no reason that it should break on OS X if it works on Windows and Linux. All this PR done is change the build process.

btw, it also compiles fine with jdk12 too. Just tested it :slightly_smiling_face:

1 Like