Since attachments are automatically removed, I created a repository on GitHub: https://github.com/hzpz/nashorn-examples
>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 >>
