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.
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?
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?
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-
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.