'. '

GraalJS

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Graal.js is the Default NetBeans 11.1 Engine)
(OMG! Nashorn got Deprecated!)
Line 15: Line 15:
=== OMG! [[Nashorn]] got Deprecated! ===
=== OMG! [[Nashorn]] got Deprecated! ===
-
The [[Apache]] [[NetBeans]] developers knew that [[Nashorn]] should be replaced, but
+
[[Nashorn]] got deprecated in [[JDK]]11. The [[Apache]] [[NetBeans]] developers knew that [[Nashorn]] should be replaced, but
weren't convinced that [[Graal.js]] was the right choice. Rather than disrupting
weren't convinced that [[Graal.js]] was the right choice. Rather than disrupting
the community I created {{NB|org.netbeans.api.scripting|org.netbeans.api.scripting|Scripting}}
the community I created {{NB|org.netbeans.api.scripting|org.netbeans.api.scripting|Scripting}}

Revision as of 14:25, 7 June 2019

GraalJS is an implementation of JavaScript on top of GraalVM with the help of Truffle APIs. It is fully open sourced at https://github.com/graalvm/graaljs

Contents

Graal.js is the Default NetBeans 11.1 Engine

With a great delight I can announce that Graal.js 19.0.0 and necessary GraalVM libraries (Truffle, Graal SDK, regex) were successfully integrated[1] into Apache NetBeans 11.1

From a distance it may appear that I am just playing with my pet project, however that would be a false impression. This perpetual, intermittent and delicate endeavor of making Graal.js the default scripting engine of NetBeans started eight months ago[2] and required orchestration of work dispersed across various source repositories and developer communities.

OMG! Nashorn got Deprecated!

Nashorn got deprecated in JDK11. The Apache NetBeans developers knew that Nashorn should be replaced, but weren't convinced that Graal.js was the right choice. Rather than disrupting the community I created Scripting which hides the actual selection of the engine behind the scene.

However, before I could integrate Graal.js engine the whole "Nashorn has to be replaced" panic escalated in December 2018 with CVE-2018-17191. The community decided to fix the problem by replacing Nashorn by Rhino! Clearly that wasn't in OracleLabs interest - we don't want to ship GraalVM's VisualVM with Rhino! As such I decided to invest all my NetBeans Founder credit and I voted -1 on the Apache NetBeans 11 release candidate. That caused quite a bit of disruption in the community and some members still feel the bitterness[3], but that change was against modularity principles of NetBeansRuntimeContainer I decided to risk my credit. At the end Apache NetBeans 11 was released without Rhino.

Fixing the (meta) Security Vulnerabilities

However, while integrating Graal.js 1.0.0 RC12 into NetBeans it turned out that it contains numerous security vulnerabilities and it cannot be used to address CVE-2018-17191 at all. That is where the second part of my journey started: I had to convince Truffle and Graal.js teams and our security architects that the issues were real and that they had to be fixed. At the end I could prevent the vulnerabilities for once and ever by securing the API itself with the invention of HostAccess configuration. My work got into 19.0.0 release and it makes all the GraalVM languages (not only JavaScript, but also Ruby, Python, R language, etc) really secure when it comes to embedding them into real products.

With the security fixes and HostAccess configuration in place I could finally integrate Graal.js 19.0.0 into Apache NetBeans and use it to address CVE-2018-17191[4].

Everything got Better!

After eight months we have better, more configurable and secured Truffle API with sandboxed Graal.js implementation on top of it. We have tested the embedability of our system into an industry adopted real world application. We prevented integration of competing scripting engines into NetBeans Platform and paved a way to smooth and unified access to all our language engines from OracleLabs IGV and VisualVM tools.

Personal tools
buy