To answer your question about the memory management I'll just quote my README:

Memory Management

When creating an object (directly or indirectly), native memory will be allocated.

Structs will always be allocated with an arena. By default an automatic arena is used, but you can use any arena you want (even a global arena, but this may not be desirable) by using the appropriate constructor.

Other classes will allocate memory with a function call. When the object is created directly with a constructor call, a cleanup function will be attached to the memory segment. By default an automatic arena is used, but you can again use any arena you want. But this means you must not free the memory yourself, as it will be freed a second time when the arena is closed (does not apply for the global arena).

When an object is not created directly, e.g. with a method call, no cleanup function will be attached to the segment (unfortunately a side effect of generating all sources). That means you need to free the memory that this object holds manually. A workaround is to use the "raw methods" to allocate the memory and then attach the cleanup function manually.

BoxShapeSettings floorShapeSettings = new BoxShapeSettings(
		new Vec3().x(100).y(1).z(100),
		Jolt.DEFAULT_CONVEX_RADIUS);

// Object is created indirectly. No cleanup function will be attached
BoxShape floorShape = floorShapeSettings.createShape(); 

// Workaround
MemorySegment floorShapeSegment = BoxShapeSettings.createShape(floorShapeSettings.memorySegment());
BoxShape floorShape = new BoxShape(floorShapeSegment.reinterpret(Arena.ofAuto(), Shape::destroy));

Nevertheless, we still need to ensure on the Java side that all pointers passed to the native code stay alive as long as they are in use.

The overhaul is already finished. In my first version (the main branch), I wrote almost everything by hand. This of course took a huge amount of effort and a long time. The hard part was not really to write the actual bindings by hand, but rather the sheer quantity of code needed and the gathering of the required information from the header file (e.g. the extensive use of typedefs adds a lot of work). At some point I decided to use libclang to parse the header file and to extract all the required information. This allowed me to generate a rough structure of the classes that were nonetheless required to be finished off by hand. For the second, overhauled version (the Overhaul branch), I have generated nearly all sources using a generator I wrote. The generator uses libclang and FreeMarker to generate bindings from a given header file. When the config files are correct, the generator outputs already fully functional bindings that do not need to be changed in any way. So when something changes, I only need to update the config files, and this requires far less effort and work.

However, generating everything comes with a loss of flexibility: If a class deviates from the default structure, then I need to provide a custom template that handles this correctly. Because this may result in additional work, I have left it out most of the time. That's the reason that, for example, the class Vec3 has no constructor that takes three floats.