New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

[Attila Szegedi]

I’m going to chime in with some thoughts, with the understanding that I’m obviously fairly biased having spent quite a few years working on all the mentioned technologies. With that:

On Nashorn:
---

Nashorn is still a complete implementation of ECMAScript 5.1 standard. The fact that ECMAScript has gone through further development since 5.1 doesn’t invalidate Nashorn as a runtime for programs written for ECMAScript 5.1, which are still a very large chunk of world’s JavaScript codebase. What is the maintenance burden for just keeping it as it is in the JDK and what are the perceived benefits of the removal?

But in any case, wouldn't it make sense to keep Nashorn until at least GraalJS can ship with JRE as its replacement, and thus not get into a situation where requesting a scripting engine for JS yields nothing in an out-of-the box JRE, which would be a situation unprecedented since Java 1.6. 

The JEP also states that "GraalJS provides most of the same functionality as Nashorn along with better performance” but at the same time "With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.” Is it presumed GraalJS developers will make a better job of maintaining it and tracking ECMAScript changes?

On Dynalink:
—

I’m frankly surprised at the suggestion to also deprecate Dynalink. Even in the case where removal of Nashorn would be justified, Dynalink is not a Nashorn-specific technology; it’s a higher-level language interoperability framework itself building on top of method handles. It has wider applicability than Nashorn. It just debuted as public API in Java 9, and hardly had enough time to prove itself on whether it’ll achieve adoption by language developers (as they need to opt in for a Java 9+ compatibility for it case.)

Speaking of adoption: Dynalink is already being adopted by Scala for its dynamic typing features. This would pull the rug from under that effort.
(If Java were ever to extend to support a similar feature – never say never – Dynalink would be in a great position to provide the underpinnings of such a feature, just as method handles did for lambda factories.)

I will allow that Dynalink could be obsolete in a world where all language interop happens under coordination of GraalVM, but that would obsolete method handles too. If the underlying intent is that GraalVM is supposed to become a mandatory part of Java and take over all such responsibilities, that’s a different issue, but there should be an open discussion about that instead.

Dynalink is also feature complete as it is; its maintenance burden should be zero. I have, upon being recently asked by former colleagues within Oracle, explicitly expressed willingness to work on any further enhancement requests for it in OpenJDK, so I’m here to answer any maintenance needs for it.

On releasing these technologies from OpenJDK
—

Finally, there could be arguments for liberating Nashorn from the core OpenJDK. If it were split off, it could be developed and released independently. Nashorn is not tied into any other JDK code, so it’s very easy to separate. Of course, any such code being moved out of OpenJDK with GPL license would have somewhat limited adoption, as the reality of the industry is that people are wary of GPL and prefer more liberal licenses (Apache, BSD, and such).

Dynalink on the other hand, being designed as an interop focal point would be significantly less useful if it were not in the JDK. It provides services to other language systems. That was the whole point of the work I undertook to shepherd it from a standalone project to a JDK component.

Attila.

> On 2018. Jun 6., at 20:16, mark.reinhold at oracle.com wrote:
> 
> http://openjdk.java.net/jeps/335
> 
> - Mark