Yep, I think I know why it happens. Are you building with Java 11?
This will happen if you build with Java 11 then run with Java 8 and lower.
Edit:
Java 9 introduces overridden methods with covariant return types for the following methods in java.nio.ByteBuffer that are used by the driver:
position
limit
flip
clear
In Java 9 they all now return ByteBuffer, whereas the methods they override return Buffer,
resulting in exceptions like this when executing on Java 8 and lower:
This is because the generated byte code includes the static return type of the method, which is not found on Java 8 and lower because the overloaded methods with covariant return types don’t exist.
The solution is to cast ByteBuffer instances to Buffer before calling the method. ((Buffer) buf).clear();
I suspect you’re on the right track. I intended for the jars to be built with openjdk8. (Prior builds used oraclejdk8.) But perhaps something went awry. I’ll look at the logs.
Travis ran 2 jobs for commit 001b593—one for the tag (2804) and one (2803) for the untagged commit, I guess. Each job had 4 builds. It looks like both 2804.1 and 2804.3 deployed (to Bintray) or tried to.
I switched the jar-uploading build from oraclejdk8 to openjdk8 because the compileBulletjmeLinux32SharedLibraryBulletjmeCpp task was failing in Travis-CI’s precise environment, and precise seemed to be the only environment that still supported oraclejdk8.
I’d be very curious to know with what JDKs (if any) the alpha3 release works.
If the NoSuchMethodError is caused by incompatibility between oraclejdk8 and openjdk8, then perhaps add yet another build to the job: build the Linux bulletjme on xenial-openjdk8 and the JARs on precise-oraclejdk8. Call it alpha4.
Unless someone comes up with a better plan, that’s what I plan to do, starting around 1500 UTC.
I am a bit late but: Does Xenial support openjdk8?
Also you need to do quite some changes to build the .so on xenial and the jar on precise, I guess.
Especially since precise will be decomissioned, we should think about switching to build on java 11 (even though all my personal projects are still java 11) or install our custom jdk for build.
If so, we could even easily add the arm changes and see what happens soon.
Actually @Ali_RS described how we could make java 11 code compatible with java 8, but I am not sure how many code has to be changed.
Still I don’t expect such problems between oracle and openjdk
The decommissioning of trusty at Travis-CI is a looming concern. I believe @RiccardoBlb is working to migrate the Engine’s continuous integration to GitHub Actions, which would address that concern.
To be clear, I just wanted to describe the reason why this NoSuchMethodError exception is happening, I do not mean that we should use this casting solution ((Buffer) buf).clear();. I yet believe JME’s builds that are deployed to Bintray should be done with Java 8.
3.3.0-alpha4 is available from jCenter, however it appears to have the same issue as -alpha3:
Sep 21, 2019 10:07:32 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.3-alpha4
* Branch: HEAD
* Git Hash: b57d823
* Build Date: 2019-09-21
Sep 21, 2019 10:07:33 AM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.2.3 build 13 context running on thread main
* Graphics Adapter: GLFW 3.4.0 Win32 WGL EGL OSMesa VisualC DLL
Sep 21, 2019 10:07:34 AM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[main,5,main]
java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
at com.jme3.util.BufferUtils.createByteBuffer(BufferUtils.java:983)
at com.jme3.renderer.opengl.GLRenderer.<init>(GLRenderer.java:80)
at com.jme3.system.lwjgl.LwjglContext.initContextFirstTime(LwjglContext.java:216)
at com.jme3.system.lwjgl.LwjglContext.internalCreate(LwjglContext.java:468)
at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:457)
at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:578)
at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:427)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:463)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:125)
at mygame.Main.main(Main.java:19)
