<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Really good progress!<br>
</p>
<div class="moz-cite-prefix">On 06/01/2023 10:31, Martin Pernollet
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;">Hi everyone,</div>
<div style="font-family: Arial; font-size: 14px;"><br>
</div>
<div style="font-family: Arial; font-size: 14px;">Thank you a lot
for your messages. I got good news to share :</div>
<div style="font-family: Arial; font-size: 14px;">
<ul>
<li><span>First, I have been able to render the OpenGL teapot
<i>inside</i> a Swing and AWT window \o/ Please see the
video attached or even try it <a href="https://urldefense.com/v3/__https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-wrappers-macos/src/main/java/demos/panamagl/macos/swing/DemoTeapot_Onscreen_macOS.java__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYeAzE3yAg$" title="on your macOS here" moz-do-not-send="true">on
your macOS here</a>.</span></li>
<li style="font-family: Arial; font-size: 14px;">Second, I
confirm that I running bindings generated for macOS 10.15
runs on 10.12. <br>
</li>
</ul>
</div>
</blockquote>
Good to know<br>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;">
<div><br>
</div>
</div>
<div style="font-family: Arial; font-size: 14px;">The pattern I am
going toward for a common interface</div>
<div style="font-family: Arial; font-size: 14px;">
<ul>
<li>Have generated bindings, generated once and deployed as<a href="https://urldefense.com/v3/__https://gitlab.com/jzy3d/panama-gl-bindings__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYfNbASRsQ$" title=" standalone maven artifacts" moz-do-not-send="true">
standalone maven artifacts</a>.</li>
<li>Have <a href="https://urldefense.com/v3/__https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-wrappers-macos/src/main/java/opengl/macos/GL_macOS_10_15_7.java__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYcr23qqcA$" title="wrappers of these bindings" moz-do-not-send="true">wrappers
of these bindings</a> implementing a <a href="https://urldefense.com/v3/__https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-core/src/main/java/opengl/GL.java__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYeHQ6CP_A$" title="common interface" moz-do-not-send="true">common
interface</a>. <br>
</li>
</ul>
</div>
</blockquote>
Do you think that that the same set of bindings will not work across
OS? Why?<br>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;"><br>
</div>
<div style="font-family: Arial; font-size: 14px;">I will generate
the common interface and the wrappers. I am thinking of using <a href="https://urldefense.com/v3/__http://www.javassist.org/__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYdt6zOTJQ$" title="Javaassist" moz-do-not-send="true">Javaassist</a>. I am
interested if you have other suggestions.</div>
</blockquote>
<p>Other options, if you are into classfile manipulation are:</p>
<p>* ASM (perhaps the more popular, what the JDK itself uses):
<a class="moz-txt-link-freetext" href="https://asm.ow2.io/">https://asm.ow2.io/</a><br>
* the brand new JDK classfile API:
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/classfile-api-dev/2022-June/000000.html">https://mail.openjdk.org/pipermail/classfile-api-dev/2022-June/000000.html</a><br>
</p>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;"><br>
</div>
<div style="font-family: Arial; font-size: 14px;">To answer the
"well-behave" nature of OpenGL</div>
<div style="font-family: Arial; font-size: 14px;">
<ul>
<li><span>Yes, there are types to hide differences per
platform. OpenGL is an API so one can expect to find the
same headers everywhere.</span></li>
<li><span>BUT OpenGL has dynamic loading capabilities to allow
getting features on computers that have hardware (GPU)
supporting some kind of rendering, and others not able to
do the same, still running on the same OS but not the same
GPU. That is a very interesting case for Panama. In that
case I'll have to rely on OpenGL API methods that load
functions only if they are supported on the host computer.</span></li>
</ul>
</div>
</blockquote>
<p>I think you refer to GL extensions - aren't there like opaque
function pointers whose existence you can query dynamically? I
think stuff like this can be made to work well with Panama. Other
projects such as the Fuse Panama port are using similar
function-pointer based approaches:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/cryptomator/jfuse">https://github.com/cryptomator/jfuse</a></p>
<p>That said, the fact that there are extensions, doesn't mean that
the jextract bindings would not be portable across OSs ? But more
that you need to write some kind of support to discover and invoke
the extension functions? (wild guess here)<br>
</p>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;"><br>
</div>
<div style="font-family: Arial; font-size: 14px;">A bit more about
OpenGL</div>
<div style="font-family: Arial; font-size: 14px;">
<ul>
<li>Sometime I have to ask the OS to do things such as
executing java runnable on the main macOS thread. For now
this requires I keep using manually generated binding from
JOGL, allowing to use Objective C code. <a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB/issues/5__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYfPT9ePYA$" title="I don't think JExtract can do this" moz-do-not-send="true">I don't think JExtract can do this</a>.</li>
</ul>
</div>
</blockquote>
<p>Does passing this option " -XstartOnFirstThread" to the JVM
works? IIRC, it was added for things like these. I think I saw
this here:</p>
<p><a class="moz-txt-link-freetext" href="https://foojay.io/today/project-panama-for-newbies-part-3/">https://foojay.io/today/project-panama-for-newbies-part-3/</a></p>
<p>Which does have an opengl tutorial for MacOs<br>
</p>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;">
<ul>
<li>There are several additional libraries to GL and GLUT,
handling OS specific things (e.g. CGL for mac, WGL for
windows, GLX for linux). I'll most probably bind to these
rather than glut. <br>
</li>
</ul>
</div>
</blockquote>
Ok - so this part is not portable, and you will need different
bindings for each OS, which seems ok.<br>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div style="font-family: Arial; font-size: 14px;"><br>
</div>
<div style="font-family: Arial; font-size: 14px;">The JavaDoesUSB
project is really great and its developer has been really nice
by providing help on JExtract, thank you for the advice! <br>
</div>
</blockquote>
Maurizio<br>
<blockquote type="cite" cite="mid:1m61FD6A1zzStcn7WwkojwuKw6yogAuEe3cqDzYMe0q7RGDAYziSX291QwszhnlDIAql094BUYUxutH0cJDciTv0LYDHw5S7QWofVvLutUE=@protonmail.com">
<div class="protonmail_signature_block" style="font-family: Arial;
font-size: 14px;">
<div class="protonmail_signature_block-user
protonmail_signature_block-empty"> </div>
<div class="protonmail_signature_block-proton"><br>
</div>
</div>
<div class="protonmail_quote"> ------- Original Message -------<br>
Le mardi 3 janvier 2023 à 18:51, Maurizio Cimadamore
<a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a> a écrit :<br>
<br>
<blockquote class="protonmail_quote" type="cite">
<p><br>
</p>
<div class="moz-cite-prefix">On 20/12/2022 15:04, Martin
Pernollet wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family: Arial; font-size: 14px;">Here's my
use case in more detail : I've been advised to generate <b>different
binding for different OS</b> (and maybe version). For
OpenGL, this lead me to a glut_h binding for macOS, one
for Windows and one for Linux.</div>
</blockquote>
<p>Expanding a bit more on this point (apologies if my
previous reply was not clear).</p>
<p>While we suggest that, in the general case, one might have
to run jextract multiple times (once per target platform),
your mileage my vary.</p>
<p>Consider the jextract code. Jextract relies on libclang, a
native library. For jextract itself, we just generate a
single copy of the bindings for both MacOS, Linux and
Windows:</p>
<p><a href="https://urldefense.com/v3/__https://github.com/openjdk/jextract/tree/master/updateclang__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYfovR2B0Q$" class="moz-txt-link-freetext" rel="noreferrer nofollow
noopener" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jextract/tree/master/updateclang</a></p>
<p>This is possible because libclang has been written in a
portable way: for instance types that are platform dependent
such as `long` have been expanded to `long long`, so that
they are 64 bits no matter what.</p>
<p>Also, the API makes extensive use of the opaque handle
pattern: that is, a lot of libclang data structures are
built inside the library itself, and then returned to
clients as opaque by-value structs, whose contents point to
the memory allocated by the library.</p>
<p>As such, the layouts of the structs defined in libclang is
never truly important, as a client will typically pass them
opaquely to other functions.</p>
<p>The combination of these two factors allow the bindings to
work seamlessly across platforms.</p>
<p>Now, while I'm not an expert on OpenGL, I seem to recall
that OpenGL is rather well-behaved when it comes to defining
new types - e.g. it defines its own primitives (GLint,
GLfloat and such). This gives me some hope that the OpenGL
bindings might, in fact, work well across multiple
platforms. <br>
</p>
<p>One complication with OpenGL is GLUT, which doesn't seem
(IIRC) to be well supported on some platforms (e.g. MacOS).
So, some tricks might be necessary there.</p>
<p>I guess the main takeaway there is that IF (big if :-)) the
library has been written in a portable way, then a single
jextract run might be all you need (maybe with some
filtering added on top to get rid of platform-dependent
functionalities, which you can do with the jextract options
already available).</p>
<p>The USB code [1] I pointed you at, on the other hand, is
much more complex, as that code needs to interface with
_different_ libraries to do its job on different platforms -
so of course that kind of unification is not something you
can achieve using a tool.</p>
<p>So, as often is the case with native code, we have a
spectrum of "badness":</p>
<p>1) well-behaved libraries (like libclang and OpenGL), which
are written with portability in mind<br>
2) libraries that are mostly portable, but might present
minor mismatches (e.g. long being 64 vs. 32 bits, some API
points not available in all platforms, etc.)<br>
3) libraries that are hopelessly platform-specific</p>
<p>I believe jextract proves that (1) already works (**). And
for (3), as stated, not much can be done.</p>
<p>So the question is whether something should be done for (2)
- and how much can be done "automagically". This will likely
require us to come up with a precise definition of the
boundaries of what gaps we can actually bridge, as (2) is a
rather fuzzy bucket.<br>
</p>
<p>(**) I can see ways in which even libraries in bucket (1)
could fail - e.g. this can happen because the symbol lookup
would fail to initialize because of different library
names/paths. This is something that we need to address, but
also something which requires a much much smaller hammer
(such as the ability to define your own symbol lookup).<br>
</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p>[1] - <a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYeDz5L8fQ$" class="moz-txt-link-freetext" rel="noreferrer nofollow
noopener" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB</a><br>
</p>
</blockquote>
<br>
</div>
</blockquote>
</body>
</html>