project is outdated. It lacks support for the
latest EcmaScript 2015 (ES6)
standard and has quality issues. Moreover, the parser on JSDT is derived
at large, leaving the JSDT committers as the sole maintainer. Luckily, there are
Eclipse JSDT which runs on a Java VM. In the last few weeks, I have been
experimenting with alternatives that enables such integration.
Before I go into the details of integration let me quickly introduce the parsers
that I have tried.
Acorn is a tiny parser written in
AST format and is extensible
to support additional languages such as JSX, QML etc.
Esprima is also a fast, tiny parser that is written in
moved to JQuery foundation and has been in
use on Eclipse Orion for a while. Just like Acorn it also
uses the ESTree AST format.
is the only Java based parser on my list. It is a relatively new parser.
It uses Shift AST as its model which is different from the widely
Why does AST model matter?
first uses a parser to generate an AST model and operates on the model to find
possible problems. As one can imagine, an IDE that uses a widely adopted AST
Eclipse JSDT already comes with a JSDT AST model that is used internally that is
very hard to replace. Therefore, regardless of the AST model generated by the
parser it will be converted to JSDT’s own model before used. Which renders
around the AST models moot in JSDT’s context.
The parsers other than Shift, which already runs on the Java VM, need a
mechanism to play nice with the Java VM. I have experimented with
3 mechanisms for running Acorn and Esprima for JSDT so far.
Utilizes node.js to run the parser code. node.js runs as an external
process, receives the content to be parsed and return the results. I have
chosen to use console I/O to communicate between node.js and Java VM. There are
also other techniques such as running an http or a socket based server for communication.
In order to avoid the start up time for node.js, which does affect the performance
significantly, node.js process is actually kept running.
provide the full functionality of node.js and can only be used to execute selected
scripts, fortunately Acorn and Esprima parsers can be run with J2V8.
The criteria for choosing a parser may vary from the feature set, to AST model
used, to even community size. However performance is the one criteria that would
make all others relevant. So in order to compare the performance of different
alternatives I have developed a number of
benchmark tests to compare parsers
and the mechanisms.
All benchmark tests produce a result with an AST model, either in
JSON form or as a Java object model. Tests avoid the startup time for their
environments, for instance the startup time for the node.js process affects
the results significantly but are discarded by the tests. The current test sets use
Table 1. Average time for each benchmark
As expected Shift parser which runs directly on top of JavaVM is the quickest solution.
To be fair, Shift parser is missing several features such as
tolerant parsing and
comments that may affect the parsing performance. However even
after these features added it may remain the quickest. I feel that the performance
for J2V8 can also improve with more creative use of the low level APIs however
there is so much memory copying between Java heap to JNI to V8 heap and back
I am not sure if it would be significant.
The surprise for me is the Esprima’s performance with Nashorn. It is unexpected in two
ways. It is actually the third quickest option however Acorn does not give the same level of