Interview with David P. Caldwell

Nashorn JavaScript Engine deprecation: “This might increase the importance of Rhino again”

Gabriela Motroc
David P. Caldwell

Ready or not, Nashorn JavaScript Engine will be deprecated once JDK 11 is here. The “massacre” of this youngling sent a shockwave across the industry. What’s the consensus on the deprecation? What alternatives are there? Should someone take over Nashorn? We talked to David P. Caldwell about all this and more.

JAXenter: How do you feel about the decision to deprecate the Nashorn JavaScript Engine?

David P. Caldwell: It’s a little sudden, coming near the end of the JDK 11 release cycle. I’m not sure how widely the information has been shared, so I’m not sure to what degree the community has been truly notified about this.

Perhaps if the deprecation is highly visible in JDK 11 we’ll get a more accurate view of how many people might be impacted. Otherwise, I can imagine a lot of people getting stuck on the last JDK to have it – migrating off an engine like that in complicated systems is hard.

JAXenter: How often do you use Nashorn? Could you give us some examples?

David P. Caldwell: I use Nashorn and/or Rhino essentially every day for custom application development. I have an open-source project SLIME that depends on them and several customer projects that depend on that.

JAXenter: The discussion around this topic is far from over. Have you talked to other people who share the same opinion? What’s the consensus on the deprecation?

I can imagine a lot of people getting stuck on the last JDK to have [Nashorn] – migrating off an engine like that in complicated systems is hard.

David P. Caldwell: People are worried, particularly with the suddenness with which it’s happened. GraalVM is being touted as a replacement, but it doesn’t even support a Hello, World application on its version of the jrunscript tool, so we’re currently unable to evaluate the sufficiency of that solution.

In any case, without a significant Nashorn compatibility layer, it’ll take some doing to port applications from one embedded JavaScript engine to another – particularly when the embedding is totally different, and it appears to me that “embedding” JavaScript in Java (my products use several layers of back-and-forth communication between the two) may be very different – in some cases, it may be easier to embed Java in JavaScript on GraalVM.

JAXenter: What other alternatives are there? Have you tried any of them? 

David P. Caldwell: I was a long-time Rhino developer, and it’s possible this will increase the importance of Rhino again. Rhino still is being maintained as an open-source project and so has a history of community involvement. For some uses, it’s clearly superior because of its faster startup time. Nashorn doesn’t have the same history of community involvement so it might be tough to build a community around it. I haven’t looked at the Nashorn code base but it also might be substantially more difficult to work with; it uses a lot of fancier stuff.

JAXenter: Is GraalVM a good alternative? 

David P. Caldwell: We. Don’t. Know. It is not ready for evaluation.

If GraalVM is a good alternative, the root cause of the consternation is that Nashorn’s deprecation was suddenly announced without GraalVM being in a sufficient state to even evaluate it as an alternative. No wonder people are worried.

GraalVM’s latest release (which somehow is numbered as a “release candidate”) can’t even run the jrunscript version of Hello, World. So I can’t see how we’re supposed to know how capable it will be.

JAXenter: The motivation behind the proposal to deprecate Nashorn was that it is “challenging to maintain”. Do you think someone should take over Nashorn? How would that work and are there any people interested in doing this?

David P. Caldwell: I think someone should take over Nashorn, yes. There are going to be people who now have code that is based on Nashorn embedding peculiarities, Nashorn private APIs (I certainly am guilty of this). These people, when Nashorn was announced as the future, and the JVM had been shipping with a JavaScript implementation since Java 6 – in other words, for TWELVE YEARS – had no reason to believe that capability would simply go away. These people need somewhere to go without being stuck on an old JDK. Nashorn does what it does, and it’s going to need to keep doing it.

GraalVM is being touted as a replacement, but it doesn’t even support a Hello, World application on its version of the jrunscript tool.

It may be more difficult to build a community around Nashorn because it has no history of community involvement. There are ex-Nashorn developers out there, some of them no longer with Oracle, and some heavy users of it. Perhaps they could be organized into a community, but it’d take some effort either by one of them or by Oracle – or by an organization like Apache.

JAXenter: Their motivation aside, why do you think Oracle has decided to deprecate Nashorn?

David P. Caldwell: I believe them that it’s difficult to keep up with the dizzying pace of changes in JavaScript. But I suspect it has more to do with GraalVM. GraalVM has kept up with the changes in JavaScript, and also will hopefully realize the benefits Avatar.js was intended to yield. Node.js has gained traction.

At one point, with the right marketing, I think Nashorn could have been a worthy competitor for the Node ecosystem. But it’s lagged in adoption and mindshare, so perhaps a if-you-can’t-beat-them-join-them approach, working hard on Node compatibility, can get Oracle another shot. We’re now looking almost at a CLR (Microsoft .NET) strategy of “write in any language.” This is a good move for the JVM, the right move. Alternative JVM languages have never gotten the love they deserve – everything from Jython to JRuby to Rhino/Nashorn – but we’ve seen some promising work done by language *inventors* like Kotlin and Scala.

GraalVM may be another chance.

JAXenter: What problems will arise if Nashorn is shot down?

David P. Caldwell: Some people are going to be left out in the cold unless Oracle provides a bulletproof Nashorn compatibility layer, leaves Nashorn available under the covers, or something. And something will be lost for the Java community as well. For better or worse, Sun, and then Oracle, have managed the Java platform with backward compatibility being absolutely sacrosanct, even hanging onto things like the brutal JDK 1.0 Date APIs as a result. That generates trust. Some of that trust will be lost here.

Thank you!

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments
Mike lawrence
Mike lawrence
3 years ago

Having written Java apps for over a decade, thus is shocking news. If anyone was considering jumping over to nodeJs, this may be the catalyst to get developers moving.

Eric Vergnaud
Eric Vergnaud
2 years ago

Whilst it is true that it’s hard to keep up with a rapidly changing JavaScript ecosystem, there are tools out there which are meant precisely to fill the gap between bleeding edge JavaScript ‘features’ and plain old ES 5.1.

Eric Vergnaud
Eric Vergnaud
2 years ago

I use Nashorn for end to end testing of JavaScript client code calling into Java server services. I use webpack to convert JavaScript language constructs into code that Nashorn understands.

Eric Vergnaud
Eric Vergnaud
2 years ago

I also believe Nashorn should be moved into an optional package, that a community could then maintain.
The level of risk that Nashorn users are willing to accept is much higher than the one the large user base of plain Java would tolerate.