[graalvm-users] Migrate from Nashhorn JSR 223 Scripting Engine to Graal

Thu Sep 6 06:47:24 PDT 2018

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). 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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=jOXWVcjYlc6M1BLiEqOu8RPJzrsXOcc6PVAjFPgek8g&s=Flhivk8PsCAwOnvOn19Cdg1tTJWSQGapBbQdWbt_8_k&e=>
>
>
>
>
>> On 22 Jun 2018, at 20:34, Andreas Mueller <am at iit.de 
>> <mailto: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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=V2rW9Bb4RXGagEjJPJ7OhMWUid7VzLtEMOH5cLmS8dw&m=jOXWVcjYlc6M1BLiEqOu8RPJzrsXOcc6PVAjFPgek8g&s=KBKaQUmRtPMwf_a83SQ5CUnUTCc13SQs3IsSk7M8jeA&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
>>
>> <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-users/attachments/20180906/cb7857da/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/20180906/cb7857da/attachment-0001.png 