main.yml: use "temurin" openjdk.

[Ali-RS]

I hope it fixes issue #1896.

[Ali-RS]

Ehm..., why build stuck on windows jdk11!

[Ali-RS]

Ok,

I hope it fixes issue #1896.

It does. I grabbed the maven artifacts uploaded on GitHub actions and it works fine on java 8.

[Ali-RS]

Unless there's something to discuss, I plan to self-integrate this PR in about 12 hours.

[MeFisto94]

tbh this is very dubious and we had that discussion somewhere (apparently after) java 11.
It may be worth checking the hub on what we've written back then.

To me, this is a clear ABI (binary) breakage (code will always compile, because "buf.flip()" will either compile to FloatBuffer#flip or Buffer#flip.).
We should check the generated IL in the class files, to see how they differ, but if changing the java distribution changes something, that's an even more severe bug.

I don't know the IL in question well enough, but I think in C#, there's explicit method references (so if you compile against Buffer#flip, it will execute that, even if you override the method). That would be even more dangerous, if it would skip the implementation of FloatBuffer#flip at runtime.

So TLDR is: I think we should take some time to investigate and solve this properly, as this has implications:

• For jme in general
• For my lwjgl2 build (that's why I don't believe we can compile with java 8 and use it on 17 or vice versa).
• The only potential solution would be multiple BufferUtils impls compiled with different versions.

Also it doesn't seem to be exactly java 11, but between 11 and 17:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/FloatBuffer.html#flip()
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/FloatBuffer.html -> see Methods declared in java.nio.Buffer -> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/Buffer.html#flip()

[MeFisto94]

tbh a completely different question would be dropping java 8 and 11 support, because 8 only has paid support, 11 will have less than half a year support, no one should start a new project not using java 17.
The only counter argument would be android and potentially web transpilers, but I guess android also isn't stuck on java 8 completely, actually you can't really translate them between versions.

[stephengold]

We discussed dropping Java 8 during the 3.5 release, and I decided to defer that change. As far as I'm concerned, that option is still on the table for the 3.6 release.

no one should start a new project not using java 17

For application projects, I agree. For libraries, using older Java provides compatibility benefits.

8 only has paid support, 11 will have less than half a year support

I don't understand what you mean here. According to Wikipedia many vendors plan to provide paid support for Java 8 SE until 2026 or later.

[Ali-RS]

So TLDR is: I think we should take some time to investigate and solve this properly, as this has implications:

Well, I believe this not only affects us but will break everyone's app using java ByteBuffer in their app and compile it with Azul OpenJDK8.

dropping java 8 and 11 support

After seeing this mess, I completely agree with dropping java 8 and 11 and moving to 17 and I believe this should be no issue for android and lwjgl2 anymore (now that we fixed lwjgl2 to run on newer java). I have previously been able to compile with java 17 using new language features on android 4.1+ using android desugaring.

But I am sure there will be opposing opinions about this and I do want core devs to decide about this so I can not do much at this point.

But we need to discuss this in another thread.

[Ali-RS]

Apparently, this still happens with the alpha2 release, my bad!

https://hub.jmonkeyengine.org/t/next-engine-release/46314/14?u=ali_rs