The current JME3 is not capable of running in a Java9 environment.
The reason is, that the access to the cleaner methods in Bufferutils is not possible anymore, since they are now hidden.
This thread is intended for discussion how to workaround/solve this. See end of this post for current ideas (i will add more as they are proposed):
Jul 05, 2016 11:54:30 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.2-5781
* Branch: master
* Git Hash: e2b6c51
* Build Date: 2016-06-23
Jul 05, 2016 11:54:31 AM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 2.9.3 context running on thread jME3 Main
* Graphics Adapter: null
* Driver Version: null
* Scaling Factor: 1
Jul 05, 2016 11:54:31 AM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make member of interface sun.nio.ch.DirectBuffer accessible: module java.base does not export sun.nio.ch to unnamed module @76fb893d
... 6 more
Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "jME3 Main"
1.) The simple way
Just remove the dispose method, and hope that the jdk9 is now finally capable of properly cleaning buffers
2.) The native way
Create a ultra small malloc/free wrapper that allows to abitrarly request and delete directbuffers.
3.) The selfmade memoryManagement way
At startup request a fixed size of directmemory (user specifiable). Then only give out subbuffers of this. Internally ensure that no part is given out twice without a further delete by manageing the free space. (Kinda similar how malloc itself works in C)
I thought it used to be written that it would just ignore the call if it couldn’t find the methods. I may be misremembering. That seems like the safest fallback to me. Then we still get the nice behavior on Java 8 and under and can tread water and hope for the best for JDK 9 while we work out a solution there.
The other options are kind of not good. (2) means we bypass any kind of knowledge the VM might have wanted about that memory. (3) means we have to deal with heap fragmentation and all kinds of other nasty things that presumably smarter people have already thought about.
whatever I do, I will try to reduce reflection usage as much as possible,
my personal favourite would be to put a interface between the bufferstuff,
and allow different implementations for buffers, as a solution working great on desktop does not necessarly make sense on android ect.
One of those solution could of course be the current implementation
Anyway this won’t affect 3.0 or even 3.1 most likely it will only affect 3.2