Generating a common interface for multiple platform specific binding

[Maurizio Cimadamore]

We do not have concrete examples showing this yet - but, if desirable, 
we can cook up something in that direction.

Maurizio

On 28/12/2022 16:06, Martin Pernollet wrote:
> Thank you for these advices! I complemented my last year notes 
> <https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/issues/14__;!!ACWV5N9M2RV99hQ!N1IqZWbHmbyQKeD-bZ56aFuRVi5ggyH3P29fbW4qQWw5aUZA5FGUXzIA2_xKtJLsPq5eP2TSyTzgXDKBuZ0Um11CORVuaFUbcokSgQ$> 
> on this topic with your suggestions.
>
> Do you have in mind code samples
>
>   * demonstrating ways to reconcile such cases,
>   * which could provide a larger view of the number of specific cases
>     one might encounter when building multi-platform native projects?
>
>
>
>
>> Another approach that might work would be to work at a lower level - 
>> and generate ad-hoc downcall method handles which automagically fix 
>> up mismatches that can arise across platforms. Note that jextract 
>> should expose the method handles it generates, so perhaps this 
>> adaptation can be done semi-automatically based on what comes out of 
>> jextract (and based on what the mismatches really are in your use case).
>>
>> I know that e.g. the JavaDoesUSB [1] project has faced similar 
>> issues, so perhaps their authors might want to share some insights here.
>>
>> Cheers
>> Maurizio
>>
>> [1] - https://github.com/manuelbl/JavaDoesUSB
>>
>> On 20/12/2022 15:04, Martin Pernollet wrote:
>>> Hi everyone,
>>>
>>> I am back on track with OpenGL binding with Panama!
>>>
>>> I have one code design / tooling question related to JExtract : is 
>>> it possible to *generate a common interface that would be 
>>> implemented by all platform specific binding* generated by JExtract 
>>> since JDK 19 or 20?
>>>
>>> Here's my use case in more detail : I've been advised to generate 
>>> *different binding for different OS* (and maybe version). For 
>>> OpenGL, this lead me to a glut_h binding for macOS, one for Windows 
>>> and one for Linux.
>>>
>>> To let *the user/developer face a single entry point*, I manually 
>>> write a GL interface 
>>> <https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/GL.java__;!!ACWV5N9M2RV99hQ!N1IqZWbHmbyQKeD-bZ56aFuRVi5ggyH3P29fbW4qQWw5aUZA5FGUXzIA2_xKtJLsPq5eP2TSyTzgXDKBuZ0Um11CORVuaFXTDX0_Zw$>. 
>>> I then define a GL_macOS_10_15_3 
>>> <https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/macos/GL_macOS_10_15_3.java__;!!ACWV5N9M2RV99hQ!N1IqZWbHmbyQKeD-bZ56aFuRVi5ggyH3P29fbW4qQWw5aUZA5FGUXzIA2_xKtJLsPq5eP2TSyTzgXDKBuZ0Um11CORVuaFWtFaPP-w$> 
>>> class that wraps the binding (!). When I expand the prototype to 
>>> Windows, I should copy paste this to GL_Windows_10 and modify the 
>>> imports to reference the appropriate bindings. The goal is to write 
>>> code like this
>>>
>>> GL gl = Platform.selectAmong(GL_macOS_10_15_3.class, 
>>> GL_windows_10.class, ...)
>>> gl.glDoSomething()
>>>
>>> I don't think there would be another way to have java developer 
>>> write *applications that ignore the target hardware*. However my 
>>> approach is stupid : time consuming and error prone because manual. 
>>> A real life case may have 10 implementations and 1000 functions.
>>>
>>> *Does JExtract provide a solution to this*? Should I create this 
>>> tool by myself based on all generated bindings ? Would anyone 
>>> *recommend something smarter*?
>>>
>>> Regards,
>>>
>>> Martin
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221228/3ba565ef/attachment-0001.htm>