<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Andreas,</p>
    <p>there is now a solution to your problem. You can use "Target type
      mapping" [1] to specify you want that custom conversion in your
      code. <br>
    </p>
    <p>Find below some pseudo-code how to do that. You will want to
      fine-tune that to your usecase (not use allowAllAccess; not use
      HostAccess.ALL; maybe include additional types). A more lengthy
      discussion you will find in <a
        href="https://github.com/graalvm/graaljs/issues/94">https://github.com/graalvm/graaljs/issues/94</a>.
      I'll also add an example of this to our FAQ in <a
        href="https://github.com/graalvm/graaljs/blob/master/docs/user/FAQ.md">https://github.com/graalvm/graaljs/blob/master/docs/user/FAQ.md</a>
      and/or our NashornMigrationGuide.md.<br>
    </p>
    <p>Best,<br>
      Christian</p>
    <p>[1] <a
href="https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/HostAccess.Builder.html#targetTypeMapping-java.lang.Class-java.lang.Class-java.util.function.Predicate-java.util.function.Function-">https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/HostAccess.Builder.html#targetTypeMapping-java.lang.Class-java.lang.Class-java.util.function.Predicate-java.util.function.Function-</a></p>
    <p><br>
      Context context =
Context.newBuilder("js").allowAllAccess(true).allowHostAccess(getHostAccess()).build();<br>
      <br>
          private HostAccess getHostAccess() {<br>
              HostAccess.Builder builder =
      HostAccess.newBuilder(HostAccess.ALL);<br>
              builder.targetTypeMapping(String.class, Integer.class,
      null, (v) -&gt; parseInt(v));<br>
              return builder.build();<br>
          }<br>
      <br>
          private int parseInt(String input) {<br>
              try {<br>
                  return Integer.parseInt(input);<br>
              } catch (Exception ex) {<br>
                  return 0; //TODO should not fail silently<br>
              }<br>
          }<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Am 29.10.2019 um 13:13 schrieb Andreas
      Mueller:<br>
    </div>
    <blockquote type="cite"
      cite="mid:B448A6EB-A390-4BFA-8F9C-B8A28DFF6505@iit.de">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Hi,
      <div class=""><br class="">
      </div>
      <div class="">I just wanted to ask if there was any change
        meanwhile? </div>
      <div class=""><br class="">
      </div>
      <div class="">I understand your arguments but it is a real pain to
        convert a huge number of JS scripts to cast it to the
        corresponding Java type. This prevents us to switch to GraalVM. </div>
      <div class=""><br class="">
      </div>
      <div class="">Thanks,</div>
      <div class="">Andreas</div>
      <div class=""><br class="">
        <div class="">-- <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=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&amp;s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&amp;e="
            class="" moz-do-not-send="true">http://www.swiftmq.com</a><br
            class="">
          <br class="">
          <span><img apple-inline="yes"
              id="83B84F5F-3B83-404C-9F89-1835608AEF55"
              src="cid:part5.E256DAD2.5A819D01@oracle.com" class=""></span><br
            class="">
        </div>
        <br class="">
        <blockquote type="cite" class="">On 6. Sep 2018, at 18:29,
          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="">
          thanks for the explanation.<br class="">
          <br class="">
          Look here (last section):<br class="">
          <br class="">
          <a
href="https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/javascript.html"
            class="" moz-do-not-send="true">https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/javascript.html</a><br
            class="">
          <br class="">
          Regards <br class="">
          Andreas <br class="">
          <br class="">
          Am 06.09.2018 um 15:47 schrieb Christian Wirth
          <a class="moz-txt-link-rfc2396E" href="mailto:christian.wirth@oracle.com">&lt;christian.wirth@oracle.com&gt;</a>:<br class="">
          <br class="">
          <blockquote type="cite" class="">Hi Andreas,<br class="">
            <br class="">
            thanks for keeping persistent on that matter.<br class="">
            <br class="">
            &gt; Actually I don’t need this graaljs “feature” at all.
            ;-)<br class="">
            <br class="">
            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.<br class="">
            <br class="">
            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.<br
              class="">
            <br class="">
            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.<br class="">
            <br class="">
            &gt; can’t you just act like Nashorn<br class="">
            <br class="">
            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 class="">
            <br class="">
            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
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_graaljs_issues_37&amp;d=DwQFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&amp;s=hpeXue5n_zc8jBsh9pyXcqtYPwNxzPfxQPuXTuD-jwY&amp;e="
              moz-do-not-send="true">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 class="">
            <br class="">
            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.).<br class="">
            <br class="">
            Best,<br class="">
            Christian<br class="">
            <br class="">
            <br class="">
            <br class="">
            <br class="">
            <br class="">
            <br class="">
            Am 06.09.2018 um 14:20 schrieb Andreas Mueller:<br class="">
            <blockquote type="cite"
              cite="mid:A0CA4089-1A8A-4994-BD7F-4EFF5501FC5F@iit.de"
              class="">Hi,<br class="">
              <br class="">
              I’ve tested the latest graalvm release and I’m
              still getting an exception due to lossy conversion.<br
                class="">
              <br 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?<br class="">
              <br 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. ;-)<br class="">
              <br class="">
              Thanks,<br class="">
              Andreas<br class="">
              <br class="">
              -- <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=DwQFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&amp;s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&amp;e="
                moz-do-not-send="true">http://www.swiftmq.com</a><br
                class="">
              <br class="">
              &lt;swiftmq_logo_positiv.png&gt;<br class="">
              <br class="">
              <br class="">
              <blockquote type="cite" class="">On 22 Jun 2018, at
                20:34, Andreas Mueller <a class="moz-txt-link-rfc2396E" href="mailto:am@iit.de">&lt;am@iit.de&gt;</a> 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). <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 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 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=DwQFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&amp;s=6HbGvcUl7MYIx3jlkj_SbRTvVqkR79D6_Vv5eLC5uUY&amp;e="
                  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 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 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 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 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="">
                -- <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=DwQFaQ&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&amp;m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&amp;s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&amp;e="
                  moz-do-not-send="true">http://www.swiftmq.com</a><br
                  class="">
                <br class="">
                &lt;swiftmq_logo_positiv.png&gt;<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 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="">
              <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 immediately and destroy this e-mail. Any
              unauthorized copying, disclosure or distribution of the
              material in this e-mail is strictly forbidden.<br class="">
            </blockquote>
            <br class="">
          </blockquote>
          <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 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>
      <br>
      <br>
      <hr>
      IIT Software GmbH<br>
      Falkenhorst 11, 48155 Münster, Germany<br>
      Phone: +49 (0)251 39 72 99 00<br>
      Managing Director: Andreas Müller<br>
      District Court: Amtsgericht Münster, HRB 16294<br>
      VAT-No: DE199945912<br>
      <br>
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 immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br>
    </blockquote>
  </body>
</html>