“GraalVM’s ambitions are much broader than those of Nashorn”
Thomas Wuerthinger: Graal.JS has been available for years – with much higher performance than Nashorn. One of the primary reasons the researchers in Oracle Labs started the GraalVM project in 2011 was out of a belief that the architectural approach of Nashorn (forcing all languages to be modeled via Java bytecodes) was the wrong approach to build VMs, for reasons of performance and in limiting the ability to provide compatibility with languages designed originally for other runtimes. So in that sense, the GraalVM team has always wanted to replace Nashorn with something better.
Investment in Nashorn has been decreasing for years, and many of the key Nashorn developers had moved on long ago.
If the question is whether or not there was some single executive within Oracle making a decision on this the answer is no. What’s happening with Nashorn now is happening organically from the engineering level as a result of the respective technical characteristics of the two engines.
JAXenter: What does GraalVM have that Nashorn doesn’t?
Thomas Wuerthinger: When the migration flag is enabled, many Nashorn applications will run without any modifications on Graal.js. In some corner cases, small modifications can be necessary. We describe those cases in our migration guide. An example is a lossy implicit conversion of numeric values when calling Java methods (eg. Nashorn will silently convert floating point values like 3.4 to the integer value 3). We prohibit such implicit conversions in order to give programmers the ability to detect bugs early rather than silently lose precision. The workaround for such a scenario is straightforward and involves only minor modifications to the code.
JAXenter: David P. Caldwell told us in a recent interview that many people might “get stuck on the last JDK to have it since migrating off an engine like that in complicated systems is hard.” What’s your take on this?
JAXenter: Nashorn was unable to run node.js applications but that’s not the case for GraalVM since it’s compatible with almost 99% of Node.js modules. Would you say that GraalVM is a better Nashorn?
Thomas Wuerthinger: Clearly we believe that GraalVM is better than Nashorn in basically any relevant dimension. We wouldn’t say it is a “better Nashorn” since our ambitions are much broader than those of Nashorn.
JAXenter: GraalVM supports interoperability with Java in mostly compatible fashion to Nashorn, with identical syntax. What are the most likely issues one can run into when upgrading to GraalVM? What’s the solution?
Thomas Wuerthinger: The GraalVM team is committed to make Nashorn migrations as easy as possible with the Nashorn compatibility mode. The migration guide in our GitHub repo has more details.
Should Nashorn be kept alive by the community?
JAXenter: According to the announcement, the Nashorn compatibility mode features are not recommended for new code. Why is that?
We haven’t seen any expressions of interest from the community in keeping Nashorn alive in the month or so since the Java team floated the idea with JEP 335.
Thomas Wuerthinger: That’s up to the Java team. I don’t think there are concrete plans at the moment and they are looking for community feedback.
JAXenter: Should Nashorn be kept alive by the community? Do you know if there are any individuals or foundations interested in keeping it alive?
Thomas Wuerthinger: No. We think the community should contribute to Graal.JS because it covers all of the Nashorn use cases and is substantially more capable on most dimensions. We haven’t seen any expressions of interest from the community in keeping Nashorn alive in the month or so since the Java team floated the idea with JEP 335.
JAXenter: What’s next for GraalVM?