
JEP 335: Deprecate the Nashorn JavaScript Engine - chrisseaton
http://openjdk.java.net/jeps/335
======
kodablah
Can someone give some background on the reasoning?

I'm glad it's not completely Oracle's call. I see this as a power move.
Nashorn is part of OpenJDK, which is becoming less and less Oracle-specific.
Graal/Truffle however are squarely under Oracle's umbrella.

> With the rapid pace at which ECMAScript language constructs, along with
> APIs, are adapted and modified, we have found Nashorn challenging to
> maintain. [...] GraalJS using Oracle Labs' Truffle technology may soon be
> publicly available as a Java module. It is understood that GraalJS provides
> most of the same functionality as Nashorn along with better performance.

So, one is too challenging to maintain but the other isn't? Why don't you just
come out and say it? You are shifting resources to your more proprietary impl
that you have a premium version of. And if no other OpenJDK maintainers want
to step up and maintain Nashorn, I say remove it. But everyone should be clear
about Oracle's motives here. I expect we'll start seeing this more and more
like we do with mission control...Oracle is going to dedicate fewer and fewer
resources to OpenJDK, the Oracle version of which no longer carries reasonable
benefits on its own. More ancillary products around the JVM will be focused
on. Makes sense, but I sure wish an alternative Oracle-effort-sized OpenJDK
maintainer existed.

And for those of you that have used Nashorn and need it to do work, remember
what is happening here. And those of you starting the same thing with
Graal/Truffle, watch what is happening here. Lots of us work w/ the core of
the JDK, but beware of building new products on Oracle tech.

~~~
tetha
What actual reason is there to build anything new on oracle? MySQL is
obsoleted by one of MariaDB, Postgres or Galera, especially for new things -
and in my book, OracleDB is as well for new things. The OpenJDK supplies
enough java to build big things and even the use of java might be debated.

This changed during the last decade, but at this point, oracle thrives on
things large corporates depend upon. There is no reason to start anything
outside of a large enterprise with Oracle investment with any oracle
dependency. Quite the opposite.

~~~
flafla2
I think Microsoft is trying (and, so far, succeeding) to consume this market
with their C#/.NET offerings. Their open-sourcing of .NET Core and their
commitment to cross-platform makes C# (which, of course, has similar syntax
and standard libraries to java) an ever more attractive option.

~~~
sjellis
"I think Microsoft is trying (and, so far, succeeding) to consume this market
with their C#/.NET offerings. Their open-sourcing of .NET Core and their
commitment to cross-platform makes C# (which, of course, has similar syntax
and standard libraries to java) an ever more attractive option."

I've seen an interview with one of the managers for .NET who said that
directly: they specifically want to compete with Java, and made the platform
cross-platform and Open Source partly because Java is those things.

------
AgentK20
Since when do new systems get integrated into Java, then officially deprecated
for removal less than 5 years later? New technologies take time to be
integrated into existing stacks, and new projects take time to come to market.
I recognize that it's a lot of work to keep up with the ECMAScript language,
but even if the ECMAScript language support lags behind official, that's
better than removing a component that was hyped up in the Java 8 release.

My team uses the Nashorn engine as a sandboxed scripting engine in an upcoming
game. Because of the nature of the transpiling of javascript into Java, we've
got very granular control over what classes, fields, and methods can be
accessed from the javascript context. I'm not sure at this point what we're
going to do about this, so I'm looking at things like GraalJS. Anyone have any
experience with a use case like ours?

~~~
kjeetgill
I'm not that familiar with Nashorn but the Truffle framework on which GraalJS
is built has considerations for sandboxing.

see: hostClassFilter()
[https://github.com/oracle/graal/blob/master/sdk/src/org.graa...](https://github.com/oracle/graal/blob/master/sdk/src/org.graalvm.polyglot/src/org/graalvm/polyglot/Context.java#L835)

I suspect that your use-case might be easier to port than most (if it comes to
that) since you probably aren't using as many platform APIs.

I agree that the volatility in java-land is new and unsettling and Nashorn is
pretty young to be removed but the js ecosystem itself has been changing fast
lately. I hope they keep Nashorn around even of they don't keep up with newer
language versions.

------
kaixi
What a shame. With Spring you could switch from traditional Java based
templates to server-side rendering React templates without changing your
controllers.

------
foobarbazetc
Sigh... we just built a whole new service with Nashorn.

~~~
sigzero
I was thinking of going that way as well. _sigh_

~~~
Touche
Mind sharing why you picked Nashorn?

~~~
foobarbazetc
We built a user scripting feature for our product (like Google App Script).
Our backend is entirely written in Scala so hooking up JS to our Scala stuff
was really, really simple with Nashorn.

The tricky bits are all the hacks to limit resource usage which took a bunch
of engineering time to implement and test and aren’t reusable across engines.

It’s not the fastest or the latest or whatever but it works well and gets the
job done.

~~~
regecks
>The tricky bits are all the hacks to limit resource usage which took a bunch
of engineering time to implement and test and aren’t reusable across engines.

Interesting.

I built the same thing. Through some basic script examples, such as
`while(true) {}` or `new Buffer(1000 * 1000);`, the conclusion that I came to
was that it is impossible to truly interrupt/prevent resource exhaustion
attacks. A bug anywhere that would allow reflection to be accessible would
have been disastrous as well.

In the end, I built a JNI wrapper over Duktape+flatbuffers, which gave me
super fine-grained control over memory allocation and CPU time.

I'd be very interested to hear a summary of how/whether you managed to make
Nashorn safe for user scripts.

~~~
foobarbazetc
We run the user supplied code through an instrumentation pass (using Google
Closure Compiler) where we modify it at the AST level to call a resource
check/interrupt check after every instruction. It also modifies any loop
constructs. The compiler will save a sourcemap so you can pretend you’re not
modifying user code.

We disable all extensions. We do some instrumentation on string ops as well.
We use the mbean API to get the memory and CPU usage of the current thread. We
have a monitor thread that checks that for all worker threads. I’ve probably
forgotten a bunch of things but it was a huge pain. I’m going to tell our guys
about your solution and see if that’s something we can look into.

~~~
Tobba_
Wouldn't code instrumentation be trivially bypassable using an eval construct?
esp. something like

    
    
      []["constructor"]["constructor"]("while (true) { }")()
    

Or does Nashorn have a mechanism for forcing the code static?

------
jameshart
Is there any relevance to this to the fact that Oracle owns the trademark on
_JavaScript_?

Usually trademarks are only maintained through use; if Oracle stops
distributing a JavaScript implementation, could they lose the trademark?

~~~
bitmapbrother
Oracle recently had Apple pull an app from the App Store because it had the
word JavaScript in the name. So they are vigorously defending the trademark.

[https://news.ycombinator.com/item?id=16862949](https://news.ycombinator.com/item?id=16862949)

------
ozten
Alternatives section is light.

Another option is to freeze Nashorn at ECMAScript-262 5.1 and not chase new ES
versions.

~~~
sparky_
Seems pretty reasonable, given the availability of JS transpilers to target
older ECMAScript implementations (Babel, for instance)

------
pradn
Has anyone used Nashorn? For what use-cases did it make sense to run JS inside
of a JVM process?

~~~
kenan_warren
I know of one CMS that uses it extensively underneath to construct the pages.

~~~
MrBuddyCasino
Yeah Alfresco. Was a stupid idea, second only to their decision to roll their
own crappy UI framework.

------
lorenzosnap
Nashorn is the beating heart for
[https://github.com/lorenzoongithub/nudge4j](https://github.com/lorenzoongithub/nudge4j)

Around 100 stars in github so probably not worth much consideration to whoever
decided to 'deprecate it'

Again, nudge4j is effectively 8 lines of Java code (just enough to kick off
the nashorn engine) and the rest is JavaScript on Java.

I hope that JEP 335 won't go ahead. I vote against.

------
kjeetgill
Question for those in the know: What are the Nashorn specific APIs and that
would break in a move to graaljs? Presumably all of the pure js code would
still be compatible with any js implementation but java/js interop and
platform apis specific to nashorn would break. How big of an api surface is
this really?

~~~
chrisseaton
> but java/js interop ... specific to nashorn would break

I think GraalJS implements the same Java/JS interop API.

~~~
kjeetgill
That's good news then.

If they're is some effort to spec out the Nashorn API and regression test
those parts against GraalJS they'd probably benefit from branding it as
Nashorn 2.0 or at least Nashorn API Compatible to assuage all the fear.

------
_bxg1
I'm not very familiar with Nashorn, but could they just create a thin Java
compatibility layer and outsource the bulk of the work to V8? Are there
license issues with shipping V8 alongside Java?

~~~
kjeetgill
The author of this proposal, Jim Laskey, is also the one behind exactly what
you're describing: Project Detroit.

see:
[http://openjdk.java.net/projects/detroit/](http://openjdk.java.net/projects/detroit/)

speculation: It looks like he wants Nashorn dead from any angle? GraalJS and
V8, lol

~~~
jnermut
I’m wondering why Project Detroit, and the background given in the Jim Laskey
preso about it, isn’t mentioned in the JEP. I’m sure it would help quell the
outrage. That project will basically be Nashorn compatible, with better
performance and ES6 and Node support. I wonder how it relates to Graal and
TruffleJS though. Seems a bit left hand/right hand from Oracle to have
competing projects like this. For anyone interested in JS on the JVM Jim’s
video is a must watch:
[https://www.youtube.com/watch?v=-JLhwsbMvjQ](https://www.youtube.com/watch?v=-JLhwsbMvjQ)

------
exabrial
Is anyone making serious use of nashorn?

------
jupp0r
TLDR:

    
    
       With the rapid pace at which ECMAScript language
       constructs, along with APIs, are adapted and modified,
       we have found Nashorn challenging to maintain.

~~~
pitaj
Please don't quote with code blocks. It forces horizontal scrolling which is a
huge pain especially on mobile.

> Just use quote arrows to signify instead

~~~
dewiz
I agree, but please fix HN too, not mobile friendly at all

~~~
hinkley
Agree. If they fixed Their CSS it would suck about half as much.

