I’ve tried searching here and otherwise google’in, but came up short. I get this in my logs alot:
Aug 04, 2020 11:27:12 PM com.jme3.util.ReflectionAllocator destroyDirectBuffer
SEVERE: Buffer cannot be destroyed: java.nio.DirectByteBuffer[pos=0 lim=48 cap=48]
I’ve tried switching to LWJGL3 in gradle build like so:
wih jmeVersion being 3.4.0
and I have tried adding
applicationDefaultJvmArgs = ["-Xmx1024m", "-Xms512m", "-XX:MaxDirectMemorySize=1024m","--add-opens", "java.base/jdk.internal.loader=ALL-UNNAMED"]
I have also tried
dispose() after calling in images for use in textures (not sure if that even makes sense to do, but I got that hint in another thread discussing the same messages).
My java versions are as follows:
openjdk 14.0.2 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)
am I missing anything or any know work arounds I can try?
I’m curious what code is invoking
destroyDirectBuffer(). Could you set a breakpoint using the debugger and print a stack trace?
applicationDefaultJvmArgs = [
"-Xmx1024m", "-Xms512m", "-XX:MaxDirectMemorySize=1024m",
java.base/jdk.internal.ref=ALL-UNNAMED are not separated things.
They should be single argument as below:
For understanding why that error happens please see here:
08:11AM - 21 Apr 20 UTC
03:37PM - 10 Oct 20 UTC
Testing 3.3.1 release candidate, although it isn't a regression. I encounter the same issues on 3.2.4-stable.
When running this example with JDK8:
Note, this error wont happen with
jme3-lwjgl3 as it does not use
So, am I doing something wrong in trying to use lwjgl3 - or I have something else entirely invoking ReflectionAllocator (even though I dont really use reflection directly)
I dont have the source for jme3 set up (I’m just adding the dependencies through gradle), but I’ll try doing that and getting a breakpoint set to dive deeper into this.
I do not know.
have you tried this as I explained?
Yes, the warning is still there
Trying to add jme3 project (from Github) as dependency:
FAILURE: Build failed with an exception.
What went wrong:
Circular dependency between the following tasks:
| ±-- :jme3-core:compileJava
| | — :jme3-core:jar
| | — :jme3-core:classes ( ))
| — :jme3-core:jar (
— :jme3-core:compileJava (*)
(*) - details omitted (listed previously)
I’m probably missing something really basic about Gradle and sources/projects.
Anyone have a link to a guide I can read on how to set up the dependencies so I can debug them ?
Also, it will print which LWJGL version you are using into the console when you start the app.
For LWJGL2 you should see this:
12:25:00,344 INFO [LwjglContext] LWJGL 2.9.3 context running on thread jME3 Main
and for LWJGL3
12:33:32,148 INFO [LwjglContext] LWJGL 3.2.3 build 13 context running on thread main`
This is written in the log when starting the app:
Aug 05, 2020 10:12:24 AM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.2.3 build 13 context running on thread main
At the very start, I do see this though (not sure its related)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jme3.util.ReflectionAllocator (file:…/jmonkeyengine/jme3-core/3.4.0-SNAPSHOT/jme3-core-3.4.0-SNAPSHOT.jar) to method sun.nio.ch.DirectBuffer.cleaner()
WARNING: Please consider reporting this to the maintainers of com.jme3.util.ReflectionAllocator
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Can you add this into your main method and show us the result?
// get a RuntimeMXBean reference
RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean();
// get the jvm's input arguments as a list of strings
List<String> listOfArguments = runtimeMxBean.getInputArguments();
listOfArguments.forEach(s -> System.out.println("ARG:" + s));
Here’s the output:
Should the line only have 1 dash perhaps? …
it should be
Thank you. That got rid of all the SEVERE warnings. Does that mean its solved or does this just “hide the problem” ?
So my original problem was solved by both LWJGL3
and the JVM args. Thank you both for chipping in.
I mean by setting this JVM arg you can keep using LWJGL2 if that is what you want.
Marked the thread solved.