DirectBufferAllocator

Development
1

Hello fellows,

Following the discussion on this issue #ReflectionAllocator is broken on JDK 16 #1674, the final agreement was using ByteBuffer.allocateDirect(int capacity) isn’t sufficient because it creates the urgency to destroy this buffer using Reflection, but now the only module using this approach is lwjgl2.

So, i opened this discussion for this particular topic to see what are the next steps to take to resolve this issue, i suggest we may try to unify the BufferAllocator on the jme3-desktop module (but this will require either lwjgl3 MemoryUtil class or jni bindings ?), so instead of LwjglBufferAllocator, it will be DesktopBufferAllocator.

BTW, i have created a PR, it resolves android issues with the ReflectionAllocator by creating a native binding #PR-Android-Buffer-Allocator, check it out if it needs something.

Do i need to do something about this step ?

image
image930×445 59.7 KB

Thank you !

2

I guess we may use a single DirectBufferAllocator on the jme3-desktop module by using lwjgl-jemalloc implementation for both lwjgl modules instead of native bindings.

3

We shouldn’t use lwjgl bindings or other native code directly in jme3-desktop.
As i proposed on github, imo we should have a class named with the same name “NativeBufferAllocator” on jme3-lwjgl, jme3-lwjgl3, jme3-android, jme3-vr etc…
And then have BufferAllocatorFactory simply use it, so it will use the right one depending on which module is included in the build script.

2 Likes