'. '

GraalJS

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 6: Line 6:
From a distance it may appear that I am just playing with my [[NetBeans|pet project]],
From a distance it may appear that I am just playing with my [[NetBeans|pet project]],
-
however that would be a false impression.
+
however that would be a false impression. This perpetual, intermittent and delicate endeavor of making [[Graal.js]] the
-
 
+
-
This perpetual, intermittent and delicate endeavor of making [[Graal.js]] the
+
default scripting engine of [[NetBeans]] started eight months ago[https://github.com/apache/netbeans/pull/1011] and required
default scripting engine of [[NetBeans]] started eight months ago[https://github.com/apache/netbeans/pull/1011] and required
orchestration of work dispersed across various source repositories and
orchestration of work dispersed across various source repositories and

Revision as of 14:21, 7 June 2019

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

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.

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.

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

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