Details
-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
Description
Consider this case:
struct Foo {
void (*cb)(int);
};
struct Foo* func();
// now want to call func()->cb(10)
Jextract currently generates a getter/setter for "cb" - the user can also inspect the functional interface for "cb" and retrieve the functional descriptor.
So, the user has all the pieces to create a method handle to call "cb" - but it's tedious to do so, since the steps are mechanical, and it's all information that jextract already has.
It would be nice if jextract was able to, for each function pointer variable (global/struct field), emit a static method wrapper which can be used to call the function. This can be done by creating a "virtual" native method handle (which takes a dynamic address) and then passing it the address retrieved by calling the getter for "cb" (in this case).
Note that the virtual method handle can be a constant, the descriptor is already a constant. Performance-wise, unless we optimize virtual calls more, we're going to take a hit, because the address is a dynamic parameter, so intrinsics will not kick in - but it will represent a boost in usability anyway.
As for naming, since in Java methods and variables have separate name spaces, we can reuse the "cb" name for the function wrapper, with no risk of clashes.
struct Foo {
void (*cb)(int);
};
struct Foo* func();
// now want to call func()->cb(10)
Jextract currently generates a getter/setter for "cb" - the user can also inspect the functional interface for "cb" and retrieve the functional descriptor.
So, the user has all the pieces to create a method handle to call "cb" - but it's tedious to do so, since the steps are mechanical, and it's all information that jextract already has.
It would be nice if jextract was able to, for each function pointer variable (global/struct field), emit a static method wrapper which can be used to call the function. This can be done by creating a "virtual" native method handle (which takes a dynamic address) and then passing it the address retrieved by calling the getter for "cb" (in this case).
Note that the virtual method handle can be a constant, the descriptor is already a constant. Performance-wise, unless we optimize virtual calls more, we're going to take a hit, because the address is a dynamic parameter, so intrinsics will not kick in - but it will represent a boost in usability anyway.
As for naming, since in Java methods and variables have separate name spaces, we can reuse the "cb" name for the function wrapper, with no risk of clashes.
