Thought I pitch in with this humble claim as some say it is pride month (chuckles)
and GlueGen got neglected in the latest overlord's endeavors.
(regardless, open for contracting and cooperation in this regard as well)
Where are we with GlueGen? - Still all offline, compile time, produced code for any Java VM >= 8
- Verifiable and human readable
- No runtime risks or 'production costs'
- Map native foreign function and native data structures to Java
- OO-Style API mapping as used in JOGL's incremental OpenGL Profile API levels
- Struct mapping reworked
- No native code required for mappings w/o function pointer
- Supporting most, if not all types including pointer-pointer and function-pointer
- Easy to use (produced) function and data mappings w/o obfuscating
runtime code data and type arrangements.
- Java callback methods to receive asynchronous and off-thread native toolkit events
- Can produces JNI_OnLoad*(..) for dynamic and static libraries to resolve JNIEnv* handling via generated JVMUtil_GetJNIEnv(..) - GlueGen also provides a comprehensive runtime library (see API doc)
Then we have talked about adding an XML frontend
next to our existing C-Header front producing the IR
(Intermediate Representation, or simply object tree/AST making up the structure
and used to produce the code -> backend).
Naturally, a Khronos XML API description is a first target,
planned to be tested with OpenGL and later with Vulkan perhaps.
Here the ownership or mapping of java userParam -> our little native
- Some want ThreadLocal?
- Some want a special key like a context?
- Example: glDebugMessageCallback(..) - Just some other argument passed to Callback-SetFunc?
- Example: OpenAL AL_SOFT_callback_buffer extension - ... you get the idea.
Right now it is sort of global to the binding instance.
One idea is to produce a CallbackFuncTypeUsrKey class,
which gets all Callback-SetFunc arguments funneled via its ctor.
This class may use any of these arguments as its key criteria
plus also use other external criteria like Thread.currentThread().
(Not performance critical here, since Callback-SetFunc gets called rarely).
Key criteria implies implementing the equals() and hashCode() functions
based on said criteria.
Of course, we would produce this class by default and only use the userParam
as key -> no default change.
The user can configure using its own CallbackFuncTypeUsrKey class definition,
where only the ctor must be same, i.e. fed with all Callback-SetFunc arguments.
User would have all freedoms to implement the actual key for the mapping.
AL_SOFT_events is now exposed in JOAL and used in ALAudioSink.
The latter uses the off-thread buffer consumed count to avoid active polling via AL,
simply using the count or waiting until expected free buffers are available.
This path removes an AL context switch and reading the processed buffers from source,
i.e. should allow a slightly more sleepy and responsive behavior.