GraalJS
From APIDesign
(→OMG! Nashorn got Deprecated!) |
|||
| (9 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[GraalJS]] is an implementation of [[JavaScript]] on top of [[GraalVM]] with the help of [[Truffle]] APIs | + | [[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 |
| + | |||
| + | === [[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]] | With a great delight I can announce that [[Graal.js]] 19.0.0 and necessary [[GraalVM]] | ||
| Line 5: | Line 7: | ||
[[NetBeans]] 11.1 | [[NetBeans]] 11.1 | ||
| - | From a distance it may appear that I am just playing with my | + | From a distance it may appear that I am just playing with my 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 | ||
developer communities. | developer communities. | ||
| - | The [[Apache]] [[NetBeans]] developers knew that [[Nashorn]] should be replaced, but | + | === OMG! [[Nashorn]] got Deprecated! === |
| + | |||
| + | [[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 | + | the community I created {{NB|org-netbeans-api-scripting|org.netbeans.api.scripting|Scripting}} facade |
| - | + | to hide the actual selection of the engine behind the scene. | |
However, before I could integrate [[Graal.js]] engine the whole "[[Nashorn]] has to be | 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 | 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 | decided to fix the problem by replacing [[Nashorn]] by [[Rhino]]! Clearly that wasn't | ||
| - | + | the right solution. For example [[OracleLabs]] don't want to ship their [[GraalVM]]'s [[VisualVM]] with [[Rhino]]! | |
| - | As such I decided to invest | + | As such I decided to invest my [[NetBeans]] Founder credit and I voted '''-1''' on the |
Apache [[NetBeans]] 11 release candidate. That caused quite a bit of disruption in | Apache [[NetBeans]] 11 release candidate. That caused quite a bit of disruption in | ||
the community and some members still feel the bitterness[https://github.com/apache/netbeans/pull/1092#issuecomment-497057267], | the community and some members still feel the bitterness[https://github.com/apache/netbeans/pull/1092#issuecomment-497057267], | ||
| - | but | + | but as the "Rhino change" was against [[modularity]] principles of [[NetBeans Runtime Container]] I decided to risk my credit. At the end Apache |
[[NetBeans]] 11 was released without [[Rhino]]. | [[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 | However, while integrating [[Graal.js]] 1.0.0 RC12 into [[NetBeans]] it turned out | ||
| Line 41: | Line 45: | ||
integrate [[Graal.js]] 19.0.0 into [[Apache]] [[NetBeans]] and use it to address | integrate [[Graal.js]] 19.0.0 into [[Apache]] [[NetBeans]] and use it to address | ||
CVE-2018-17191[https://github.com/apache/netbeans/pull/1092]. | CVE-2018-17191[https://github.com/apache/netbeans/pull/1092]. | ||
| + | |||
| + | === Everything got Better! === | ||
After eight months we have better, more configurable and secured [[Truffle]] API | After eight months we have better, more configurable and secured [[Truffle]] API | ||
| - | with sandboxed [[Graal.js]] implementation on top of it. | + | with sandboxed [[Graal.js]] implementation on top of it. The quality was tested by |
| - | + | embeding the interpreter into an industry adopted real world application. We have opened [[NetBeans]] to scripting with many languages like [[Ruby]], [[Python]], | |
| - | + | [[R]] and more. See the tutorial at {{NB|org-netbeans-libs-graalsdk|org/netbeans/libs/graalsdk|package-summary}}. | |
| - | + | ||
| - | [[ | + | |
Current revision
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 facade to hide 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 the right solution. For example OracleLabs don't want to ship their GraalVM's VisualVM with Rhino! As such I decided to invest 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 as the "Rhino change" was against modularity principles of NetBeans Runtime Container 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. The quality was tested by embeding the interpreter into an industry adopted real world application. We have opened NetBeans to scripting with many languages like Ruby, Python, R and more. See the tutorial at package-summary.
Follow
