[graalvm-users] Migrate from Nashhorn JSR 223 Scripting Engine to Graal
Christian Wirth
christian.wirth at oracle.com
Wed Oct 30 10:08:12 PDT 2019
Hi Andreas,
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.
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 https://github.com/graalvm/graaljs/issues/94. I'll also add an
example of this to our FAQ in
https://github.com/graalvm/graaljs/blob/master/docs/user/FAQ.md and/or
our NashornMigrationGuide.md.
Best,
Christian
[1]
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-
Context context =
Context.newBuilder("js").allowAllAccess(true).allowHostAccess(getHostAccess()).build();
private HostAccess getHostAccess() {
HostAccess.Builder builder = HostAccess.newBuilder(HostAccess.ALL);
builder.targetTypeMapping(String.class, Integer.class, null,
(v) -> parseInt(v));
return builder.build();
}
private int parseInt(String input) {
try {
return Integer.parseInt(input);
} catch (Exception ex) {
return 0; //TODO should not fail silently
}
}
Am 29.10.2019 um 13:13 schrieb Andreas Mueller:
> Hi,
>
> I just wanted to ask if there was any change meanwhile?
>
> 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.
>
> Thanks,
> Andreas
>
> --
> Andreas Mueller
> IIT Software GmbH
> http://www.swiftmq.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&e=>
>
>
>
>> On 6. Sep 2018, at 18:29, Andreas Mueller <am at iit.de
>> <mailto:am at iit.de>> wrote:
>>
>> Hi Christian,
>>
>> thanks for the explanation.
>>
>> Look here (last section):
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/prog_guide/javascript.html
>>
>> Regards
>> Andreas
>>
>> Am 06.09.2018 um 15:47 schrieb Christian Wirth
>> <christian.wirth at oracle.com>:
>>
>>> Hi Andreas,
>>>
>>> thanks for keeping persistent on that matter.
>>>
>>> > Actually I don’t need this graaljs “feature” at all. ;-)
>>>
>>> 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.
>>>
>>> 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
>>> => int conversions.
>>>
>>> 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.
>>>
>>> > can’t you just act like Nashorn
>>>
>>> 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.
>>>
>>> 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 (https://github.com/graalvm/graaljs/issues/37
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_graaljs_issues_37&d=DwQFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&s=hpeXue5n_zc8jBsh9pyXcqtYPwNxzPfxQPuXTuD-jwY&e=>).
>>> 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.
>>>
>>> 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.).
>>>
>>> Best,
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am 06.09.2018 um 14:20 schrieb Andreas Mueller:
>>>> Hi,
>>>>
>>>> I’ve tested the latest graalvm release and I’m still getting an
>>>> exception due to lossy conversion.
>>>>
>>>> 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?
>>>>
>>>> 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. ;-)
>>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>>> --
>>>> Andreas Mueller
>>>> IIT Software GmbH
>>>> http://www.swiftmq.com
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com&d=DwQFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&e=>
>>>>
>>>> <swiftmq_logo_positiv.png>
>>>>
>>>>
>>>>> On 22 Jun 2018, at 20:34, Andreas Mueller <am at iit.de> wrote:
>>>>>
>>>>> Hi Christian,
>>>>>
>>>>>> 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?
>>>>>
>>>>> I didn’t test it yet. It’s not open source either (the scripts are
>>>>> under Apache 2 but the SwiftMQ is not).
>>>>>
>>>>> 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.
>>>>>
>>>>> Javadoc of the Stream Interface, FYI (sometimes we just use
>>>>> a Runnable as the callback interface):
>>>>>
>>>>> http://www.swiftmq.com/products/router/swiftlets/sys_streams/si/javadoc/index.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com_products_router_swiftlets_sys-5Fstreams_si_javadoc_index.html&d=DwQFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&s=6HbGvcUl7MYIx3jlkj_SbRTvVqkR79D6_Vv5eLC5uUY&e=>
>>>>>
>>>>>
>>>>>> > What we need is in fact a Nashorn replacement as a scripting
>>>>>> engine as part of the JDK
>>>>>> > or as a plugin into the JDK by adding it to the classpath.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>>
>>>>>> > Nashorn’s performance is ok for us but an increase would be much
>>>>>> > appreciated. Are there plans to provide that?
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Interpreted is not an option for us.
>>>>>
>>>>> Thanks,
>>>>> Andreas
>>>>> --
>>>>> Andreas Mueller
>>>>> IIT Software GmbH
>>>>> http://www.swiftmq.com
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swiftmq.com&d=DwQFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=zenR0rlRfS2eOcu2DvpgYMGFuufo57cWv5zeDfJfndw&s=UuzNObx0M8twLhJye4cigfutTdU18WjwA2OE8RAaDSM&e=>
>>>>>
>>>>> <swiftmq_logo_positiv.png>
>>>>>
>>>>>
>>>>>
>>>>> IIT Software GmbH
>>>>> Falkenhorst 11, 48155 Münster, Germany
>>>>> Phone: +49 (0)251 39 72 99 00
>>>>> Managing Director: Andreas Müller
>>>>> District Court: Amtsgericht Münster, HRB 16294
>>>>> VAT-No: DE199945912
>>>>>
>>>>> 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.
>>>>> _______________________________________________
>>>>> GraalVM-Users mailing list
>>>>> GraalVM-Users at oss.oracle.com
>>>>> https://oss.oracle.com/mailman/listinfo/graalvm-users
>>>>
>>>>
>>>>
>>>>
>>>> IIT Software GmbH
>>>> Falkenhorst 11, 48155 Münster, Germany
>>>> Phone: +49 (0)251 39 72 99 00
>>>> Managing Director: Andreas Müller
>>>> District Court: Amtsgericht Münster, HRB 16294
>>>> VAT-No: DE199945912
>>>>
>>>> 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.
>>>
>>
>>
>> IIT Software GmbH
>> Falkenhorst 11, 48155 Münster, Germany
>> Phone: +49 (0)251 39 72 99 00
>> Managing Director: Andreas Müller
>> District Court: Amtsgericht Münster, HRB 16294
>> VAT-No: DE199945912
>>
>> 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.
>> _______________________________________________
>> GraalVM-Users mailing list
>> GraalVM-Users at oss.oracle.com
>> https://oss.oracle.com/mailman/listinfo/graalvm-users
>
>
>
> ------------------------------------------------------------------------
> IIT Software GmbH
> Falkenhorst 11, 48155 Münster, Germany
> Phone: +49 (0)251 39 72 99 00
> Managing Director: Andreas Müller
> District Court: Amtsgericht Münster, HRB 16294
> VAT-No: DE199945912
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-users/attachments/20191030/48b0c711/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swiftmq_logo_positiv.png
Type: image/png
Size: 10241 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/graalvm-users/attachments/20191030/48b0c711/attachment-0001.png
More information about the GraalVM-Users
mailing list