jdk.nashorn.api.scripting.ScriptUtils.wrap

[Kockert, Timo]

Hi Sundar,

thanks for the quick reply!



I attached a small Maven project with two tests. Both tests work fine with JDK8u60. Both will fail with JDK8u31, the method selection test will also fail with newer JDKs up to JDK8u51.

The behavior demonstrated by the mapping test was the reason we used ScriptUtils in our Java code. You are right, this is not necessary as of JDK8u40. But it still counts as an API change for me.

I think we had another issue a few months ago when we updated the JDK, but I’m still trying to remember. However, those are two changes that forced us to change our code to make it work again. Maybe we used Nashorn in a way it was not supposed to be used. Or maybe the changes were not intended to have any impact on Nashorn users. In any case I would appreciate some kind of "official" statement on the matter.

Thanks again
Timo



>The ScriptUtils methods are supposed to be called only from *scripts* - 
>which the javadoc comments makes it very clear. Why do you call it from 
>Java? When calling from script, the particular static type of method 
>parameters should not make any difference.
>
>Besides, when crossing Javascript to java boundary, all script objects 
>are mirrored (wrapped) automatically now. There should be no need for 
>Java side to explicitly call wrap/unwrap at all. Will you please given 
>an example of your use-case?
>
>Also, what other API instability concerns you have? Will you please be 
>more explicit on those?
>
>Thanks,
>-Sundar
>
>On 11/9/2015 3:27 PM, Kockert, Timo wrote:
>> Hello everyone,
>>
>> on October 7th, Richard Evans posted to this mailing list (with the same subject as me):
>>
>> "Sometime after jdk1.8u32 this method changed to take an internal jdk.nashorn.internal.runtime.ScriptObject argument.  This means that code compiled with 1.8u20 will not work with later releases, and vice versa.
>>
>> Was this change intentional?  Is this API now fixed for all future jdk1.8 and 1.9 releases?“
>>
>> I would very much like to know the same thing. Unfortunately, he didn’t get an answer. Could anyone please provide some insights?
>>
>> We’ve been using Nashorn since early 2015 now and there has been more that one occasion, when a newer JDK behaved differently (in respect to Nashorn) than an older JDK (up to the point of the aforementioned compile error). I guess my real question is, how stable is Nashorn’s API?
>>
>> Thanks
>> Timo
>