<div dir="ltr">Hi Maurizio,<div>thanks for the detailed response!</div><div><br></div><div>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?</div><div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 24, 2023 at 12:22 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    <p>Hi Clayton<br>
      interacting with JNI code has few issues:<br>
      <br>
      1. you need a JNIEnv* segment<br>
      2. you need to be able to wrap Java objects as JNI references (so
      that they can be passed as pointers to native calls)<br>
      3. expose some way to map method names into JNI mangled names (so
      that we can look those up using a symbol lookup)<br>
    </p>
    <p>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:</p>
    <p>* 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)<br>
      * a true JNILinker <: Linker - this might allow a tighter
      coupling with JNI functions (as the JNIEnv will be passed
      automatically)<br>
    </p>
    <p>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).</p>
    <p>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:<br>
    </p>
    <p>native long makeGlobalRef(Object o) // call NewGlobalRef, cast
      result to jlong and return<br>
      native void destroyGlobalRef(long ref) // cast to jobject, then
      call DeleteGlobalRef<br>
      native Object readGlobalRef(long ref) // cast to jobject, return<br>
      native long getEnv(); // cast env parameter to jlong and return<br>
    </p>
    <p>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.</p>
    <p>Cheers<br>
      Maurizio<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div>On 24/05/2023 18:28, Clayton Walker
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">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 <a href="https://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interface.html" target="_blank">here</a> I assume we need jni in order
        to access the native PlatformInfo struct. My question is the
        same as asked in <a href="https://stackoverflow.com/questions/75620948/how-do-i-get-the-hwnd-of-a-canvas-using-panama" target="_blank">this stackoverflow question</a>, is it
        possible to use panama to get the HWND of a swing window?</div>
    </blockquote>
  </div>

</blockquote></div>