Nashorn deprecation

Tue Jul 3 23:21:19 UTC 2018

Oh, another note about picking the Truffle JS over Nashorn: it will
mean there's no supported JS implementation that runs on non-Graal
runtimes. That doesn't seem like the future we want for JVM JS.

- Charlie

On Tue, Jul 3, 2018 at 6:19 PM, Charles Oliver Nutter
<headius at headius.com> wrote:
> I was going to start another thread, but I thought it made sense to reply here.
>
> I see the justification for deprecating Nashorn is given as "it's too
> hard to maintain". I'd like to understand if that's the real
> justification or if the real truth is that the Truffle JS impl is
> going to be preferred by Oracle going forward.
>
> I am also curious, in that case, if the question is about performance.
> I have been running JRuby -- a far less complex language
> implementation than Nashorn -- atop Graal JIT with great results.
> Numeric benchmarks are competitive with the Truffle implementation of
> Ruby, and with better inlining and a bit of data structure
> specialization I'd expect many more scenarios to perform well too.
> Truffle goes a long way on the specialization and inlining front, but
> the bulk of its gains appear to be from partial escape analysis --
> gains I am seeing on JRuby without any modification.
>
> I've just posted a blog entry about running JRuby on Graal JIT, which
> shows how a mandelbrot algorithm is many times faster using
> *unmodified* JRuby on Graal.
>
> http://blog.headius.com/2018/07/running-jruby-on-graal-jit.html
>
> This is without JRuby doing any numeric specialization of code, which
> Nashorn does very aggressively.
>
> So what's the actual reason for deprecating Nashorn? Are we
> deprecating having a standard JS shipped with OpenJDK, or are we just
> picking a winner? Are we sure it's the right winner?
>
> - Charlie
>
> On Fri, Jun 15, 2018 at 3:50 PM, Paulo Lopes <pmartins at redhat.com> wrote:
>> Hi Tony,
>>
>> By no means a solution, but at the vertx project I've managed to get a small layer that allows you to run the same script (unmodified) both on nashorn or Graal JS (not node)
>>
>> https://github.com/reactiverse/es4x/pull/12
>> https://github.com/reactiverse/es4x/pull/16
>>
>> This is what we're experimenting to smoothly allow us to run on JDK8,9,10,11 and Graal.
>>
>>
>> Cheers,
>> Paulo
>>
>>   Original Message
>> From: tonyzakula at gmail.com
>> Sent: June 15, 2018 22:29
>> To: jluzon at riotgames.com
>> Cc: yikesaroni at gmail.com; nashorn-dev at openjdk.java.net
>> Subject: Re: Nashorn deprecation
>>
>> Also replied to the thread.  Our entire platform is built on Nashorn.
>> Assumed it was the Java answer for JS on the Java runtime.
>>
>>
>> On Mon, Jun 11, 2018 at 8:57 PM Jesus Luzon <jluzon at riotgames.com> wrote:
>>
>>> Is there any way to reply to a thread before I was subscribed? I'm pretty
>>> much a noob when it comes to this mailing list process.
>>>
>>> As for the deprecation, we use Nashorn heavily for our Edge transformation
>>> layers and would need to find something that's at least backwards
>>> compatible with our use case. Our use case is actually quite simple so I
>>> think it would be easy to get functionality again, but would rather find
>>> something that will last more than a few years without heavy maintenance.
>>>
>>> On Mon, Jun 11, 2018 at 1:56 PM, Attila Szegedi <szegedia at gmail.com>
>>> wrote:
>>>
>>> > Hey folks,
>>> >
>>> > the best thing you can do is answer to this thread on jdk-dev mailing
>>> > list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
>>> > 001338.html>. The JEP is a candidate, and they’re gathering feedback
>>> > there. If there’s a lot of community feedback saying people use and
>>> depend
>>> > on Nashorn, it’ll be taken into consideration. Lots of people have
>>> already
>>> > chimed in on that thread already saying they rely on Nashorn. If you can
>>> > re-post your below messages in that thread, it’d be the best. If you are
>>> > not subscribed to jdk-dev, you can do so at <
>>> http://mail.openjdk.java.net/
>>> > mailman/listinfo/jdk-dev>.
>>> >
>>> > Paulo, your specific experience of already having tried to replace
>>> Nashorn
>>> > with GraalVM.js might be particularly significant.
>>> >
>>> > Best regards,
>>> >   Attila.
>>> >
>>> >
>>> > > On 2018. Jun 11., at 21:35, Paulo Lopes <pmartins at redhat.com> wrote:
>>> > >
>>> > > Hi,
>>> > > As the "core" developer of JS support for Vert.x this is quite some
>>> > > shocking news as the project really relies on Nashorn for JS support.
>>> > > I've been spending many hours to get GraalVM.js working and to some
>>> > > extent we can run some unmodified application with it, but we're not
>>> > > there yet. For example Nashorn dynalink and Multi threading support are
>>> > > not there yet.
>>> > > It would be nice to hear what's the ETA for the removal, will project
>>> > > Detroit provide a JS script engine (ala Nashorn and will it be
>>> > > available as a replacement?)...
>>> > > Cheers,Paulo
>>> > > On Mon, 2018-06-11 at 14:50 -0300, João Paulo Varandas wrote:
>>> > >> Hello Yikes. Well pointed... that is a drag indeed.
>>> > >> Any news on those questions?
>>> > >>
>>> > >> We are completely reliant to this feature in our platform, a lot
>>> > >> ofsoftware customization is made using ECMAScript and runs on top
>>> > >> ofNashorn/JDK8 currently. I was surprised and scared when I saw
>>> > >> that.Hopefully, Jim will bring us good news.
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Thu, Jun 7, 2018 at 9:31 AM, yikes aroni <yikesaroni at gmail.com>
>>> > >> wrote:
>>> > >> Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
>>> > >> dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
>>> > >> questions:
>>> > >> 1) So what is the last planned release of Nashorn? J9? It wasnt'
>>> > >> clear fromthe JEP.
>>> > >> 2) Is this deprecation specifically to make room for GraalJS? That
>>> > >> is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
>>> > >> afully-supported, not-just-for-research GraalJS?
>>> > >> Thanks. Important stuff to know for planning for projects dependent
>>> > >> onNashorn / JS support in the JVM!
>>> > >>
>>> > >>
>>> >
>>> >
>>>