| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Native pascal strings shall be just treated as normal Java strings on the Java side.
Hence drop the length parameter across generated API, i.e.
- C Function bindings
- Java Callbacks
|
|
|
|
| |
defines, include native expression
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
927bbc7160a812bb29c0e7120d4a3009bfb13bbf
Almost done
|
|\ \
| | |
| | |
| | | |
'Mathieu_Fery/feature/prevent_callback_generation_if_setter_is_absent'
|
| | |
| | |
| | |
| | | |
related isn't present
|
|\ \ \
| | | |
| | | |
| | | | |
'Mathieu_Fery/feat/array_accessor_with_getter_of_field_in_pascal_case'
|
| |/ /
| | |
| | |
| | | |
with field with name in PascalCase or camelCase
|
| |/
|/|
| |
| |
| |
| | |
JavaConfiguration.requiresJavaCallbackCode()"
This reverts commit 927bbc7160a812bb29c0e7120d4a3009bfb13bbf.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Method was encapsulated in commit d4e8ecc3b4f68b86d95ec951971a0fea20217988
and questioned whether it is required.
The non-userParam callback case adds no additional code requirements.
Both, callback with and without userParam shares same code path
and the respective native static fields.
Only that the non-userParam code path adds additional native static fields,
but all code sections are produced in both cases.
Passed all unit tests.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'String')
Use case: String type as userParam, barely tested and not useful.
However, let's pass through all cases in our code.
Added LOG INFO for mapped types.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TBD: Is this even required?
- needsIntermediateOperation -> needsJavaCallbackCode
- Use JavaConfiguration.requiresJavaCallbackCode(..)
TBD: Is this even required?
As far as I see, the non-userParam callback case adds no additional code requirements.
Both, callback with and without userParam shares same code path
and the respective native static fields.
Only that the non-userParam code path adds additional native static fields,
but all code sections are produced in both cases.
|
|\ \
| | |
| | |
| | | |
'Mathieu_Fery/feature/java_callback_without_user_data' into pulled
|
| |/ |
|
|/
|
|
| |
compound attribute
|
|
|
|
| |
non-compound `UserParam` types to have more clarity in resulting API
|
|
|
|
|
|
|
|
|
| |
Resolves use case where UserParam reflects e.g. a context (AL_SOFT_events)
and will be (part of) the key mapping.
Implementation required an additional userParamID -> userParam mapping for default Object/ID usage.
Added 2 test cases.
|
|
|
|
| |
JavaCallbackDef/JavaCallbackKey: Always define both parameter indices; emitJavaStaticCallback(): Use cbFuncBinding and cbFuncKeyIndices from callback parameter to build key
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prelim code for JavaCallback use-case emitBodyMapCToJNIType()
It is common in toolkit APIs that a string might not be passed as a 'nul' terminated (EOS) C string,
but as a Pascal string with a given length argument.
A C string is specied as
ArgumentIsString alEventCallbackInject 3
while allowing multiple indices ..
A Pascal string can be specified as
ArgumentIsPascalString ALEVENTPROCSOFT 3 4
while allowing multiple indice-tuples for length and value ..
The tuple consist of the length agrument-index first (usually an int)
followed by the value argument-index (usually a 'char*').
+++
CMethodBindingEmitter.emitBodyMapCToJNIType(), where PascalString is implemented,
is currently being used for
- JNI return statement (no PascalString impact possible)
- JavaCallback C type -> JNI type, PascalString impacting
|
|
|
|
| |
agnostic 'emitJNIEnvDecl()' (declaration) in JNI code; Detach the thread from the JVM if newly attach in callback!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native heap, support Struct UserParam ...
Implementation now generates a static Java callback dispatcher for each defined SetCallbackFunction, which gets invoked by the generated native static counterpart with all arguments required.
The static callback utilizes its own synchronization for thread-safety and fetches the required data set stored at SetCallbackFunction to dispatch the call to the users' CallbackFunction.
In case the callback has been removed already, the static callback simply bails out quietly.
The native code does not create, release or manage heap memory and therefore is considered safe.
+++
Further Struct Type UserParam are now supported including Heterogeneous UserParam mapping (read GlueGen_Mapping.*).
+++
Cleaned up code by extracting all JavaCallback emitter code into JavaCallbackEmitter class in one place,
leaving JavaMethodbindingEmitter and CMethodbindingEmitter mostly in their original stage (non-convoluted).
In this regard, I had to refactor a few function, i.e. moving CMethodbindingEmitter.getJNIMangledArg(..)
into JavaType.appendDescriptor(..) and JavaType.appendJNIDescriptor(..) while reusing the toJNIMethodDescriptor(..) conversion.
Test4JavaCallback covers and passes all cases.
|
| |
|
|
|
|
| |
for: isPrimitive && !isPointer && staticElemCount && maxOneElement
|
|
|
|
|
|
|
|
|
|
|
| |
expose 'Key' to public and use it. Expose release*() and get*Keys() methods
Further we use a dedicated lock Object used in the Java implementation.
TODO: Native static callback dispatch code shall
- (also) acquire the lock
- handle case where the data has been released already
to render this solution thread-safe and data-race free
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resources via 'JavaCallbackKey' config and custom `SetCallback-KeyClass`
Updated unit test and doc accordingly.
Unit tests handle OpenAL's AL_SOFT_callback_buffer and AL_SOFT_events.
Tested global scope (no key, default) and 1 key (default) and 1 key (custom class).
Added more query functions, which all only take the `SetCallbackFunction` key arguments as specified.
Cleaned up JavaCallback* config class field naminig scheme.
Added 'synchronized (..Map) { }' block in crucial `SetCallbackFunction`,
rendering implementation thread safe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added code generation incl. native to Java dispatch and resource management
Tested via Test4JavaCallback.java (using test2.[hc]).
Please read the GlueGen_Mapping.md as well as Test4JavaCallback.java .
+++
Some implementation details:
JavaConfiguration maps JavaCallbackDef to JavaCallback set-function and maintains a list.
JavaCallbackDef itself holds all configured details.
JavaConfiguration also maps JavaCallbackInfo to JavaCallback set-function.
JavaCallbackInfo itself holds all compile time information, as produced by JavaEmitter.beginFunctions(..).
This extends JavaCallbackDef and avoid repetetive computation for the callback-function-type and its MethodBinding,
parameter indices for the callback interface and userParam, etc.
CMethodBindingEmitter: Native callback to Java dispatch
- The JavaCallback setter function creates a native 'UserParam' struct instance,
which holds the callback-interface-jobject, its callback-jmethodID and
the userParam-jobject for invocation of the actual JavaCallback interface method.
- To produce the C-Type -> JNI-Type conversion, An internal CMethodBindingEmitter instance
for the native-callback function binding is created inside the CMethodBindingEmitter of the callback setter method.
It is being used to map the types to JNI within the generated native callback function,
passed to the actual JavaCallback method.
JavaMethodBindingEmitter: Native callback to Java dispatch
- The JavaCallbacl setter passes the callback-interface-object, the userParam-object and the
callback-method-signature (to have the native method retrieve the jmethodID).
- It receives the native pointer of the native `UserParam` struct instance,
which gets mapped to the userParam-object. (*TODO: Refine ownership + release*).
|
| |
|
|
|
|
| |
`JNI_OnLoad_<LibraryBasename>(..)` for static libraries and `JVMUtil_GetJNIEnv(..)` to resolve the `JNIEnv*` as used by JavaCallback
|
|
|
|
|
|
| |
`Opaque` configured pointer-types
.. includes cross-ref'ed doc and unit test
|
|
|
|
| |
across *Emitter (needed for CMethodEmitter as well); Add JavaCallback.methodSignature to be passed to native function later on to find the callback jmethodID
|
|
|
|
| |
names, used in CMethodBindingEmitter; Use JavaCallback's function-pointer-type capital-name as simple-class-name and its FQN for JNI resolution.
|
|
|
|
|
|
|
|
|
|
|
|
| |
generated callback interface mapping the callback function.
This passes the jobject for the callback function/interface and the userParam (from 'void*')
down to the native implementation.
TODO: Add specific native implementation for JavaCallback,
wrapping the jobject's into a native struct as user-param
and a universal C-function as the native callback to dispatch
the call to the java method with known arguments.
|
|
|
|
|
|
| |
interfaces, TODO implementation
Note: JavaCallbackDef is commented out on test2.cfg example, since implementation is missing.
|
|
|
|
| |
where it could occur -> non-opaque, non-primitive array case
|
| |
|
|
|
|
| |
JavaEmitter.getConfig(), cleaning up API usage
|
|
|
|
| |
See documentation and unit test test2.h, Test2FuncPtr.java and Test3PtrStorage.java
|
|
|
|
|
|
|
|
|
|
| |
enhance API doc; Add getArrayBaseOrPointerTargetType() and getTargetFunction()
Added getArrayBaseOrPointerTargetType() returns getBaseType() for arrays or getTargetType() for pointer,
i.e. stops traversing if an elementType is a pointer and returns the elementType as target-type.
This resolves 'int* intPtrArray[10]', but also simplifies all cases of 'int** intPtrPtr' and 'int intPtr[10]' etc.
Since get{Base,Target}Type() returns the functionPointer, getTargetFunction() allows to retrieve the actual target function type.
|
|
|
|
| |
remove '"' in message
|
|
|
|
| |
get<FuncName>()
|
|
|
|
| |
documentation
|
|
|
|
| |
getElementType(); Rename getBase{Elem ->}Type() to align with getTargetType()
|
|
|
|
| |
Add emitCustomJNICode(..) for JavaEmitter.endFunctions() not just structs and fix the JNI-c stub code
|
|\ |
|
| | |
|
| |
| |
| |
| | |
Ownership.Native _and_ native memory potentially gets replaced
|
| |
| |
| |
| | |
API-Doc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
in struct (like 'int') ..
We already support platform dependent sizes like pointer etc, no reason to drop e.g. 'int'.
Note: 'int' is also always 32bit of size within our current set of supported platforms, e.g. MachineDataInfo.
Further fix and clarify primCElemFixedSize and primElemSizeExpr, only to be true and set if isPrimitive.
|
| |
| |
| |
| | |
'void', i.e. exclude if !baseCElemType.hasSize() // like 'void*' -> 'void'
|