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.
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. From here I could pass the WGPU display pointer and have it interact with the swing window. 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. > >
