<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Christian,</div><div><br></div><div>thanks for the explanation.</div><div><br></div><div>Look here (last section):</div><div><br></div><div><a href="https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/javascript.html">https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/javascript.html</a></div><div><br></div><div>Regards&nbsp;</div><div>Andreas&nbsp;</div><div><br>Am 06.09.2018 um 15:47 schrieb Christian Wirth &lt;<a href="mailto:christian.wirth@oracle.com">christian.wirth@oracle.com</a>&gt;:<br><br></div><blockquote type="cite"><div>
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  
  
    <p>Hi Andreas,</p>
    <p>thanks for keeping persistent on that matter.<br>
    </p>
    <p>&gt; Actually I don’t need this graaljs “feature” at all. ;-)</p>
    <p>In fact you would; you need a new Graal.js/Truffle feature that
      converts the value for you. From a Java perspective, you are
      providing a wrong data type according to the method signature. You
      trust JavaScript to convert correctly, according to some defined
      (?) semantics of selecting the right method and right conversion.</p>
    <p>The reason why we don't have this by default is two fold: first,
      we try to provide something that works across more languages, not
      just JS between Java; and secondly, we think such a feature can
      cause way more trouble than it solves, especially if you go as far
      as String =&gt; int conversions.</p>
    <p>But yes, I acknowledge that this feature could simplify the
      migration from Nashorn to Graal.js, especially if you don't have
      an API on either side that does that already and you cannot
      introduce such API.</p>
    <p>&gt; can’t you just act like Nashorn</p>
    <p>Are you aware of any documentation (outside source code) that
      describes Nashorn's semantics on this, that your code depends on?
      In what order (of target data types) do you expect we try to
      convert to, if ambiguous - especially when methods with more than
      one arguments are involved? We have seen behavior that is
      dependent on the ordering of method definitions in the Java class
      file; that is something we cannot easily support. We have seen
      errors arise from JS code trusting its numeric data is int, while
      it was double (or the other way round) unexpectedly; that's not
      something we can solve automatically in the engine. <br>
    </p>
    <p>We are still working on providing better compatibility. One of
      the next improvements will be to explicitly select which
      method+signature you want to call
      (<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_graaljs_issues_37&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CUkXBxBNT_D5N6HMJ5T9Z6rmvNKYsqupcbk72K0lcoQ&m=LETFcLiDp6nL1aajmPXZOEqOetRaEBuuCT71duvzwF4&s=T1b6Ge4ri0oqkOQZ4t_7yeQSHquiMblzrTBNWV7WS68&e=">https://github.com/graalvm/graaljs/issues/37</a>). This won't solve
      the problem of conversion, but allows to mitigate the issue of
      seemingly random selection of methods that are called. Feel free
      to file any issues you come across in our Github Issue tracker; we
      can prioritize issues of high interest.<br>
    </p>
    <p>Note that the Nashorn Compatibility Mode is not something we
      would encourage you to use on the long run. It helps you to
      migrate more easily now, but with it enabled, you might miss newer
      features of Graal.js/GraalVM, or run into compatibility issues in
      your JS code (JSAdapter has been superseded by ES6's Proxy, that
      JS Strings are in fact java.lang.Strings is an implementation
      detail that might not be correct forever, etc.).</p>
    <p>Best,<br>
      Christian<br>
    </p>
    <p><br>
    </p>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 06.09.2018 um 14:20 schrieb Andreas
      Mueller:<br>
    </div>
    <blockquote type="cite" cite="mid:A0CA4089-1A8A-4994-BD7F-4EFF5501FC5F@iit.de">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      Hi,
      <div class=""><br class="">
      </div>
      <div class="">I’ve tested the latest graalvm release and I’m still
        getting an exception due to&nbsp;lossy conversion.</div>
      <div class=""><br class="">
      </div>
      <div class="">Actually I have a JS var that contains a String but
        is an int and the Java method call is int. I know that graaljs
        is restrictive here but can’t you just act like Nashorn when in
        Nashorn compatibility mode?</div>
      <div class=""><br class="">
      </div>
      <div class="">I mean I know that I pass a String containing an int
        so I am responsible for that. Actually I don’t need this graaljs
        “feature” at all. ;-)</div>
      <div class=""><br class="">
      </div>
      <div class="">Thanks,</div>
      <div class="">Andreas</div>
      <div class=""><br class="">
      </div>
      <div class="">--&nbsp;<br class="">
        Andreas Mueller<br class="">
        IIT Software GmbH<br class="">
        <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com&amp;d=DwMFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=jOXWVcjYlc6M1BLiEqOu8RPJzrsXOcc6PVAjFPgek8g&amp;s=Flhivk8PsCAwOnvOn19Cdg1tTJWSQGapBbQdWbt_8_k&amp;e=" class="" moz-do-not-send="true">http://www.swiftmq.com</a><br class="">
        <br class="">
        &lt;swiftmq_logo_positiv.png&gt;<br class="">
        <br class="">
      </div>
      <div class=""><br class="">
        <blockquote type="cite" class="">On 22 Jun 2018, at 20:34,
          Andreas Mueller &lt;<a href="mailto:am@iit.de" class="" moz-do-not-send="true">am@iit.de</a>&gt; wrote:<br class="">
          <br class="">
          Hi Christian,<br class="">
          <br class="">
          <blockquote type="cite" class="">Did you try if it worked if
            you annotated it? Or is your code (or relevant parts of it)
            open-source so we can run it ourselves?<br class="">
          </blockquote>
          <br class="">
          I didn’t test it yet. It’s not open source either (the scripts
          are under Apache 2 but the SwiftMQ is not).&nbsp;<br class="">
          <br class="">
          The scripts are using a SwiftMQ Stream Interface (the Java
          part provided by SwiftMQ). The intention is to use any JSR 223
          available scripting engine so that scripts (SwiftMQ&nbsp;Steeams)
          can be written in JS, Groovy, Scala, Python etc. We have only
          tested (and implemented it) in JS. So I can add annotattions
          but would rather appreciated if you don’t&nbsp;require them at all.<br class="">
          <br class="">
          Javadoc of the Stream Interface, FYI (sometimes we just use a
          Runnable as the callback interface):<br class="">
          <br class="">
          <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com_products_router_swiftlets_sys-5Fstreams_si_javadoc_index.html&amp;d=DwMFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=jOXWVcjYlc6M1BLiEqOu8RPJzrsXOcc6PVAjFPgek8g&amp;s=KBKaQUmRtPMwf_a83SQ5CUnUTCc13SQs3IsSk7M8jeA&amp;e=" class="" moz-do-not-send="true">http://www.swiftmq.com/products/router/swiftlets/sys_streams/si/javadoc/index.html</a><br class="">
          <br class="">
          <br class="">
          <blockquote type="cite" class="">&gt; What we need is in fact
            a Nashorn replacement as a scripting engine as part of the
            JDK<br class="">
            &gt; or as a plugin into the JDK by adding it to the
            classpath.<br class="">
            <br class="">
            Executing Graal JavaScript on a stock JDK is possible
            already (without Graal as optimizing compiler), and we are
            working on a fully-performant solution for JDK 11
            (with&nbsp;Graal). Graal JavaScript tries to be closely
            compatible to Nashorn, but it is unrealistic that it ever
            provides 100% compatibility. Feedback like yours helps us
            understand what&nbsp;users care about most.<br class="">
          </blockquote>
          <br class="">
          We have a lot of scripts we can test again GraalVM, no
          problem. Just post it when you have a new release and I’ll
          give it a try.<br class="">
          <br class="">
          <blockquote type="cite" class=""><br class="">
            &gt; Nashorn’s performance is ok for us but an increase
            would be much<br class="">
            &gt; appreciated. Are there plans to provide that?<br class="">
            <br class="">
            Graal JavaScript is significantly faster than Nashorn on
            most peak performance benchmarks (often orders of magnitude
            faster). But please note the difference: Nashorn
            always&nbsp;compiles the JavaScript code it executes to bytecode.
            Graal JavaScript requires Graal as optimizing compiler to
            achive good performance. The setup you are testing right
            now&nbsp;does not include Graal, so in your case, JavaScript is
            only interpreted, thus you will experience a performance
            impact.<br class="">
          </blockquote>
          <br class="">
          Interpreted is not an option for us.<br class="">
          <br class="">
          Thanks,<br class="">
          Andreas<br class="">
          --&nbsp;<br class="">
          Andreas Mueller<br class="">
          IIT Software GmbH<br class="">
          <a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CUkXBxBNT_D5N6HMJ5T9Z6rmvNKYsqupcbk72K0lcoQ&m=LETFcLiDp6nL1aajmPXZOEqOetRaEBuuCT71duvzwF4&s=VD3G6oKXwIU0NxbxItw-6QsYKcCfH2b0KKFnn_jlLPs&e=">http://www.swiftmq.com</a><br class="">
          <br class="">
          <span id="imap://christian%2Ewirth%40oracle%2Ecom@stbeehive.oracle.com:993/fetch%3EUID%3E/INBOX%3E42926?header=quotebody&amp;part=1.2.2&amp;filename=swiftmq_logo_positiv.png">&lt;swiftmq_logo_positiv.png&gt;</span><br class="">
          <br class="">
          <br class="">
          <br class="">
          IIT Software GmbH<br class="">
          Falkenhorst 11, 48155 Münster, Germany<br class="">
          Phone: +49 (0)251 39 72 99 00<br class="">
          Managing Director: Andreas Müller<br class="">
          District Court: Amtsgericht Münster, HRB 16294<br class="">
          VAT-No: DE199945912<br class="">
          <br class="">
          This e-mail may contain confidential and/or privileged
          information. If you are not the intended recipient (or have
          received this e-mail in error) please notify the
          sender&nbsp;immediately and destroy this e-mail. Any unauthorized
          copying, disclosure or distribution of the material in this
          e-mail is strictly forbidden.<br class="">
          _______________________________________________<br class="">
          GraalVM-Users mailing list<br class="">
          <a class="moz-txt-link-abbreviated" href="mailto:GraalVM-Users@oss.oracle.com">GraalVM-Users@oss.oracle.com</a><br class="">
          <a class="moz-txt-link-freetext" href="https://oss.oracle.com/mailman/listinfo/graalvm-users">https://oss.oracle.com/mailman/listinfo/graalvm-users</a><br class="">
        </blockquote>
        <br class="">
        <div class=""><br class="">
        </div>
      </div>
      <br>
      <br>
      <hr>
      IIT&nbsp;Software&nbsp;GmbH<br>
      Falkenhorst&nbsp;11,&nbsp;48155&nbsp;Münster,&nbsp;Germany<br>
      Phone:&nbsp;+49&nbsp;(0)251&nbsp;39&nbsp;72&nbsp;99&nbsp;00<br>
      Managing&nbsp;Director:&nbsp;Andreas&nbsp;Müller<br>
      District&nbsp;Court:&nbsp;Amtsgericht&nbsp;Münster,&nbsp;HRB&nbsp;16294<br>
      VAT-No:&nbsp;DE199945912<br>
      <br>
This&nbsp;e-mail&nbsp;may&nbsp;contain&nbsp;confidential&nbsp;and/or&nbsp;privileged&nbsp;information.&nbsp;If&nbsp;you&nbsp;are&nbsp;not&nbsp;the&nbsp;intended&nbsp;recipient&nbsp;(or&nbsp;have&nbsp;received&nbsp;this&nbsp;e-mail&nbsp;in&nbsp;error)&nbsp;please&nbsp;notify&nbsp;the&nbsp;sender&nbsp;immediately&nbsp;and&nbsp;destroy&nbsp;this&nbsp;e-mail.&nbsp;Any&nbsp;unauthorized&nbsp;copying,&nbsp;disclosure&nbsp;or&nbsp;distribution&nbsp;of&nbsp;the&nbsp;material&nbsp;in&nbsp;this&nbsp;e-mail&nbsp;is&nbsp;strictly&nbsp;forbidden.<br>
    </blockquote>
    <br>
  

</div></blockquote><BR />
<BR />
<HR />
IIT&nbsp;Software&nbsp;GmbH<BR />
Falkenhorst&nbsp;11,&nbsp;48155&nbsp;Münster,&nbsp;Germany<BR />
Phone:&nbsp;+49&nbsp;(0)251&nbsp;39&nbsp;72&nbsp;99&nbsp;00<BR />
Managing&nbsp;Director:&nbsp;Andreas&nbsp;Müller<BR />
District&nbsp;Court:&nbsp;Amtsgericht&nbsp;Münster,&nbsp;HRB&nbsp;16294<BR />
VAT-No:&nbsp;DE199945912<BR />
<BR />
This&nbsp;e-mail&nbsp;may&nbsp;contain&nbsp;confidential&nbsp;and/or&nbsp;privileged&nbsp;information.&nbsp;If&nbsp;you&nbsp;are&nbsp;not&nbsp;the&nbsp;intended&nbsp;recipient&nbsp;(or&nbsp;have&nbsp;received&nbsp;this&nbsp;e-mail&nbsp;in&nbsp;error)&nbsp;please&nbsp;notify&nbsp;the&nbsp;sender&nbsp;immediately&nbsp;and&nbsp;destroy&nbsp;this&nbsp;e-mail.&nbsp;Any&nbsp;unauthorized&nbsp;copying,&nbsp;disclosure&nbsp;or&nbsp;distribution&nbsp;of&nbsp;the&nbsp;material&nbsp;in&nbsp;this&nbsp;e-mail&nbsp;is&nbsp;strictly&nbsp;forbidden.<BR />
</body></html>