Generating a common interface for multiple platform specific binding

[Duncan Gittins]

For what its worth, I was interested to find that the simple Freeglut / 
OpenGL demo programs I've tried on Windows also work on my WSL Ubuntu 
with the Windows generated jextract classes via X server.

All I changed was remove the "-l opengl32 -l freeglut" parameters from 
Windows jextract run so that it did not inject the Windows loadLibrary 
calls into RuntimeHelper.java, and substitute equivalent code into the 
demo instead, like this

         System.out.format("Initialise freeglut for os.name=%s%n", 
System.getProperty("os.name"));
         final String[] libs = 
System.getProperty("os.name").startsWith("Windows")
                             ? new String[]{"opengl32", "freeglut"} :  
new String[]{"glut"};
         for (String lib : libs) {
             System.out.format("loadLibrary(\"%s\")%n", lib);
             System.loadLibrary(lib);
         }

I guess I am lucky the APIs and struct used by the simple code sample 
are consistent.

Kind regards

Duncan


On 20/12/2022 15:51, Maurizio Cimadamore wrote:
>
> Hi Martin,
> at the time of writing, jextract does not have a solution for this.
>
> I also believe that a general solution might not even exist - 
> sometimes the bindings can vary quite wildly across different 
> platforms, and there could be significant layout mismatches which 
> would be hard to reconcile. For instance on Windows, C_LONG is a 
> layout with type ValueLayout.OfInt, whereas on Linux x64 the type is 
> ValueLayout.OfLong. On top of that, some subset of native functions 
> might only be available on some platforms but not in others, etc.
>
> Considering all this, while some automated solution might be possible 
> for the use case you have in mind, most surely it would fail to scale 
> to the general case - so the general recommendation is to generate 
> different bindings (one per platform) and then come up with some 
> abstraction layer on top (which is sort of what you are trying to do). 
> 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 (e.g. if a function is 
> available in two platforms with a parameter mismatch int vs. long, 
> adapt the int-accepting method handle to take a long, so that a 
> uniform signature can be used). 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://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/GL.java>. 
>> I then define a GL_macOS_10_15_3 
>> <https://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/macos/GL_macOS_10_15_3.java> 
>> 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/jextract-dev/attachments/20230108/e75b69d2/attachment-0001.htm>