I have tested it on my machine with JDK 8 and JDK 11, on Windows 10.
Can others please test it on Windows, and other platforms with both JDK 11, and JDK 8 to confirm that it works for them.
If you have any feedback, I would love to hear it.
But we have not tested it in JME, to get sure if it works with JME, my suggestion is to create a new branch on JME github and push this PR with jdk 8 set as source compatibility.
After that we can create a jme-test-android app based on gradle project to test all jme examples on android.
Another thing to note is that Java 7 is no longer supported, with support ending for 8 in the near future. Most applications can upgrade from 7 to 8 with little to no changes.
It is a great idea to test Java 8 with Android and JME.
I think the bigger issue that was pointed out is that even though there is android support for Java 8, it looks like this is limited to API level 26 and up, AKA: Android 8.0 and up.
The only way to advance with the current java version is to have a separate Android branch. I don’t know if that’s a great idea but I also don’t know of any other way.
Regarding javax.jws.Oneway if we really need to keep it, we can use javax.jws-ap maven artifact.
We just need to add this to dependencies in build.gradle. I am using it right now with java 11 and it works fine
dependencies {
...
// We need this module as it is removed from java 10
// Oneway annotation in this module is used in JME RMI
// https://mvnrepository.com/artifact/javax.jws/javax.jws-api
compile group: 'javax.jws', name: 'javax.jws-api', version: '1.1'
...
}
Regarding this Base64 thing:
First, it is only used in GltfLoader, and it is in jme3-plugins module and I think this module will never be used in Android (unless some one wants to load gltf in android) so we are not really limited to Android 8 plus.
Also if you think this really matters again we can yet use the old javax.xml.bind.DatatypeConverter with java 8 and 11 we can simply use JAXB API maven artifact: https://mvnrepository.com/artifact/javax.xml.bind/jaxb-api/2.4.0-b180830.0359
So we can keep compatibility in all java versions: 7, 8, 9, 10, 11, 12, …
It’s not just dependencies. Lambda expressions and all the other additions won’t compile on older versions so it very much depends on how the code is written, too.
It’s unreasonable to expect everyone to not use the new language additions. For example I don’t explicitly infer diamond operators? I can’t use collection streams? It would be really annoying.
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.
Edit:
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.
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.