Panama and Swing/AWT support

Clayton Walker clayton.m.walker at gmail.com
Wed May 24 19:36:38 UTC 2023


Hi Maurizio,
thanks for the detailed response!

I believe I understood this for the most part, but a quick question related
to the jni references. Do we need to use NewGlobalRef so that we can exit
the native jni function and not have their jni reference freed?

Also would it make more sense to go this route than to expose a new
function called (e.g.) getDrawingSurface method to the awt Component class
which returns a MemorySegment that we can free? Presumably to avoid
cluttering up awt/swing with additional native function calls, or perhaps
avoid leaking implementation details to the java standard library?

On Wed, May 24, 2023 at 12:22 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Clayton
> interacting with JNI code has few issues:
>
> 1. you need a JNIEnv* segment
> 2. you need to be able to wrap Java objects as JNI references (so that
> they can be passed as pointers to native calls)
> 3. expose some way to map method names into JNI mangled names (so that we
> can look those up using a symbol lookup)
>
> This is something on our radar and we will like to address this use case
> at some point (but it is possible this might be addressed _after_ the FFM
> API is finalized). Two possible approaches are:
>
> * a set of static helper functions which allow to obtain JNIEnv segment,
> as well as create, dereference and destroy JNI refs. We might even expose
> JNI functions here (think of a JNIUtils class)
> * a true JNILinker <: Linker - this might allow a tighter coupling with
> JNI functions (as the JNIEnv will be passed automatically)
>
> I think the former approach is quite attractive in terms of bang for
> bucks. It doesn't add a lot of complexity to the API, and adds the minimum
> functionality that is required in order to allow the native linker to deal
> with JNI functions as well (even though developers will need to take some
> extra care when doing so).
>
> In the meantime, I think it might be possible to define a small JNI
> library which takes care of the missing functionalities - e.g. it could
> return/accept JNI references as "jlong" (an hack, I know) so, something
> like this:
>
> native long makeGlobalRef(Object o) // call NewGlobalRef, cast result to
> jlong and return
> native void destroyGlobalRef(long ref) // cast to jobject, then call
> DeleteGlobalRef
> native Object readGlobalRef(long ref) // cast to jobject, return
> native long getEnv(); // cast env parameter to jlong and return
>
> I've tried something along those lines and it seems to work as expected.
> But I agree that it would be convenient if this "just worked" out of the
> box.
>
> Cheers
> Maurizio
>
>
>
> On 24/05/2023 18:28, Clayton Walker wrote:
>
> I am working on a project with one of the goals being able to use a swing
> component as a render target. From the documentation here
> <https://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interface.html> I
> assume we need jni in order to access the native PlatformInfo struct. My
> question is the same as asked in this stackoverflow question
> <https://stackoverflow.com/questions/75620948/how-do-i-get-the-hwnd-of-a-canvas-using-panama>,
> is it possible to use panama to get the HWND of a swing window?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230524/7e90f7ea/attachment-0001.htm>


More information about the panama-dev mailing list