
<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <p>This is nice.</p>

    <p>I'd note here that we started with something similar a long time

      ago and then we saw that if the JDK provided a low-level enough

      API, it would have been possible for other parties to provdie

      higher-level story (with annotations, etc.) which seems what you

      have done here.</p>

    <p>I belive where I'm confused is here:</p>

    <blockquote type="cite" cite="mid:CANghgrSsWygA3=J2hc3UeL_bYVYYn12iRne35Xp_pGXnMXvkXA@mail.gmail.com">

      <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>

      </div>

      <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">But it would be

        nice to take the idea a step farther and get rid of the

        interface altogether.</div>

    </blockquote>

    <p>What is the problem with the interface?</p>

    <p>Note that, alone, just calling via a native method won't help

      with platform dependency, as you will still need to "pick" a

      signature that is ok for _all_ platform, and adapt the method

      handle under the hood accordingly. So, in terms of "portability"

      interface vs. method is the same.</p>

    <p>In terms of usability they are also the same: an interface method

      is just a method, checked by javac (and IDEs) -- same as a native

      method.</p>

    <p>Is it startup you are worried about? If so, I agree, the cost

      model of JNI and FFM is very different, but I think we need a more

      holistic approach to address that. If my guess is incorrect,

      please expand more of why you think proxied interfaces are bad.<br>

    </p>

    <p>Maurizio<br>

    </p>

  </body>

</html>