Interview with Thomas Wuerthinger, Senior Research Director at Oracle Labs leading the GraalVM project

“GraalVM’s ambitions are much broader than those of Nashorn”

Gabriela Motroc
© Shutterstock / Dmitriy Rybin

When one door closes, another opens; Nashorn JavaScript Engine will be deprecated in September but fear not, GraalVM is here to save the day. Is it a better Nashorn though? Yes and no. “GraalVM’s ambitions are much broader than those of Nashorn,” Thomas Wuerthinger explains. Let’s dive deeper into this matter.

Nashorn JavaScript Engine is (almost) dead. Long live GraalVM!

JAXenter: Oracle published a proposal [JEP 335] to deprecate the Nashorn JavaScript Engine but it seems they are taking away with one hand and giving with the other. Oracle Labs has just released another engine which supports JavaScript on the JVM: GraalVM. Was this planned all along? To “kill” Nashorn so that GraalVM can thrive?

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.

What’s new is that at the beginning of 2018, Oracle Labs open-sourced all of the GraalVM languages including JavaScript and “launched” the product this April as a way of indicating that we believe that GraalVM was ready for prime-time.  This makes GraalVM a viable replacement for most use cases of Nashorn and clearly had some impact on the decision of the Java team to start talking publicly about deprecating Nashorn.  However, 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: That’s a long list, but the short answer is 4x-6x more performance, full compliance with the latest JavaScript standards, the ability to run in the most popular JavaScript server framework Node.js, and the ability to run MANY languages, not just JavaScript.  You can get more details on that in our recent Medium post or at

JAXenter: GraalVM has been designed to support running in a variety of languages and in a variety of engines, which means that some of the APIs for Java – JavaScript interactions are different than the API choices that Nashorn’s designers made. In short, converting an existing Nashorn application to GraalVM for a unified Java/JavaScript platform could involve some tedious rewrite. To ease migration for Nashorn users who are interested in supported alternatives, the GraalVM team has added a new Nashorn compatibility flag (–nashorn-compat). How would that work? 

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?

Thomas Wuerthinger: We had a conversation with David Caldwell on Twitter and I think we resolved his issue.  There was a bug that he identified, but his concern was primarily due to his JavaScript usage depending on “jrunscript”, which is a script tool included in the JVM that the Java team has called “experimental and unsupported” since JDK 7.  So, we don’t think his first experience will be representative for other Nashorn migrations.

SEE ALSO: Meet GraalVM, Oracle’s polyglot virtual machine

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?

Thomas Wuerthinger: Three reasons–style, consistency and performance.  For example, Nashorn has two ways to get the property of a Java object from JavaScript: and obj.getProperty().  The GraalVM architects believe that having two ways to do the same thing is bad style.  We also think that it is desirable to have multilingual interop across any pair of languages be done in a consistent way, and not just designed around Java to JavaScript mappings.

JAXenter: When will the Nashorn support end? Will people have enough time to migrate to theGraalVM JavaScript implementation?

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?

Thomas Wuerthinger: We are working on getting additional languages production-ready with the high levels of library compatibility that we do for JavaScript.  The team is working hard on Python, Ruby & R as primary targets right now.  We also have a lot of performance and security-related projects in the works as well that we’ll be talking about more in the future.

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