On 10/6/26 3:20 PM, alex cole wrote:
ZjQcmQRYFpfptBannerEnd
Overall goal: Have WGPU render to a swing window entirely in Java,
zero native code. There will have to be some glue code, that may be
best to have at the JDK layer.
This would likely be a core library addition utilizing the FFM api.
I'm not sure I envisage anything at the Java API level.
Perhaps a documented native entry point that you could use with FFM -
you'd hand it an AWT window and
it would return the ID you want.
So all interaction is native.
Except that FFM doesn't handle Java objects so that entry point would
have to be able to locate the VM and
then make appropriate JNI calls.
Realistically there needs to be a way to interact with the native
pointer that can be the unilized by that systems graphics api.
Jextract can fill this void for windows.h and x11. Cocoa so far looks
a little more difficult.
Are you saying you've somehow used jextract to generate some Java
classes that will report back to you the
HDC and XID for a top-level Java window ?
Since we don't export any header files for jextract to run on I'm not
sure how you did that.
From here I could pass the WGPU display pointer and have it interact
with the swing window.
So you think all you need is the window ID ?
Would it really be sufficient ? JAWT has locking mechanisms and ways to
tell you about changes in size.
-phil.
On Thu, Jul 23, 2026 at 5:09 PM Philip Race <[email protected]>
wrote:
I don't think I understand your request and use case well enough.
Do you have a display pointer (do you really mean a window ID?) which
means you are operating in native code already ?
Or are you asking for a Java API to provide the window ID for some
AWT
top-level so you can use it with FFM ?
The request for an FFM AWT class also needs more explanation as to
what
you expect that to provide.
Even if under the covers we use FFM, I'm not sure why we'd need to
expose FFM.
If it is a request to have a Java API that consumes your native
window
ID, that isn't in any obvious way requiring FFM to be exposed, or
even
tied to FFM in any way.
-phil.
On 7/11/26 5:00 AM, alex cole wrote:
> In the JDK there is Native AWT, however there is not a way to
interact with
> it with the foreign function memory api. Could a FFM AWT class
be provided
> in the JDK?
>
> What I am trying to do is to have an easy way to utilize a
display pointer
> in a swing/javafx application. I think this could technically be
done as a
> library, but the library owner would have to keep up with every
platform
> that the JDK supports.