Nov 17, 2015

Benchmarking JavaScript parsers for Eclipse JSDT

The JavaScript parser for the Eclipse JSDT project is outdated. It lacks support for the latest EcmaScript 2015 (ES6) standard and has quality issues. Moreover, the parser on JSDT is derived from the JDT’s Java parser, hence it is not adopted by the JavaScript community at large, leaving the JSDT committers as the sole maintainer. Luckily, there are good quality JavaScript parsers that already support a large number of tools built around it. However, these parsers, like most of the JavaScript tools, are developed using JavaScript and requires additional effort to integrate with 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 JavaScript that supports the latest ES6 standard. It is one of the most adopted parsers and used by several popular JavaScript tools. It parses JavaScript to ESTree (SpiderMonkey) 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 JavaScript, which also supports the latest ES6. Its development has been recently 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.


Shift(java) 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 adopted ESTree.

Why does AST model matter?

AST model is what actually what tools operate on. For instance a JavaScript linter 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 model can utilize the ecosystem of JavaScript tools more efficiently.

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


A JNI based wrapper that bundles V8 JavaScript VM. It provides a low level Java API to execute JavaScript on bare V8 engine. Although it uses V8, it does not 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 JavaScript engine that is nowadays built into Java 8. Provides a simple high level API to run JavaScript.

Performance Benchmarks

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 AngularJs 1.2.5 and JQuery Mobile 1.4.2 (JQM) as the JavaScript code to be parsed.

Table 1. Average time for each benchmark
Parser(Script) Runtime Score Error

Acorn (AngularJS)


118.229 ms

± 1.453

Acorn (JQM)


150.250 ms

± 4.579

Acorn (AngularJS)


181.617 ms

± 6.421

Acorn (JQM)


177.265 ms

± 9.074

Acorn (AngularJS)


59.115 ms

± 0.698

Acorn (JQM)


34.670 ms

± 0.250

Esprima (AngularJS)


98.399 ms

± 0.77

Esprima (JQM)


114.753 ms

± 1.007

Esprima (AngularJS)


73.542 ms

± 0.450

Esprima (JQM)


73.848 ms

± 0.885

Shift (Angular)


16.369 ms

± 1.019

Shift (JQM)


15.900 ms

± 0.325

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 source location, 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 performance.

Read more →

Oct 1, 2015

5 Cordova project configurations for iOS and Android

Apache Cordova command line tool(CLI) provides a unified way to manage and build mobile applications across platforms. Unfortunately, it is not always possible to provide configuration options generic enough that span all supported platforms. For those cases, Cordova takes a platform specific approach.

Here is a small guide for 5 of these less known configuration options. All of these options are managed on the config.xml file on your project. As attributes of the root widget node.

  1. android-packageName

    Normally, the the package name for an Android application is generated from the id of the Cordova application. Presence of android-packageName on the config.xml causes the package name on AndroidManifest.xml and java package name for the activity class to be generated from its value.

  2. android-activityName

    The android-activityName attribute allows the main activity name to be specified. Activity name is one of those things that cannot change in Android. Therefore this feature becomes useful when renewing an older implementation with a Cordova based one or upgrading between Cordova versions that have different default activity name values.

  3. android-versionCode

    Sets the versionCode value on the application’s manifest file. If android-versionCode is not specified versionCode is generated to have the default value of 1. If you are wondering why the default value is 1 instead of the value of the version attribute, this is because versionCode is restricted to be an integer.

  4. ios-CFBundleIdentifier

    ios-CFBundleIdentifier determines the value of CFBundleIdentifier key in the Info.plist file of your application. This key is the unique identifier for your application on the system. If ios-CFBundleIdentifier is not specified the value of the id field will be used when generating Info.plist.

  5. ios-CFBundleVersion

    This is the iOS cousin of the android-versionCode explained earlier. They pretty much serve similar purpose on their respective platforms. You should be aware of the quirks when defining the value. If ios-CFBundleVersion is not specified the value of the version attribute is used for generating the iOS application.

Here is a complete example that specifies all the values:

  <widget id="" version="0.0.1"
    xmlns="" xmlns:cdv=""

Read more →

Jul 29, 2015

Try Red Hat's Mobile Application Platform on Openshift

You can now try the Red Hat Mobile Application Platform (RHMAP) yourself. This is the platform that Red Hat acquired last year and now there is a version of it running on Openshift online. If you have an Openshift online account, browse to and request your invite. Both Openshift online and RHMAP invite are free.

As a bonus, here is a video that shows how to use JBoss Developer Studio 9 and RHMAP together to build Apache Cordova based applications.

Read more →

Mar 20, 2015

What is new on Eclipse Thym 0.2.0

We have just released a new version of Eclipse Thym.

Compared to 0.1.0 release the highlights for the 0.2.0 release are.
  • Working sets are supported on New Hybrid Mobile Project wizard: You can add your Hybrid Mobile projects to JavaScript working sets during project creation.
  • Convert existing Eclipse projects to a Hybrid Mobile project: Any existing Eclipse project, that has a proper config.xml and www directory, can be converted using the Configure > Convert to Hybrid Mobile Project menu item. This feature also introduces a new API to enable adopters to programmatically convert existing projects to Hybrid Mobile projects.
  • Icon and Splash Screen support for iOS and Android builds:  If your config.xml has icon and/or splash screen references. Native project or executable exports created from Thym will honour them. Refer to Apache Cordova documentation for details of icon and splash screen support. 
As usual Thym 0.2.0 is available from these update sites and Eclipse marketplace.
  • Update existing installs:
  • Release repository good for building against:
Read more →

Jan 2, 2015

GPIO with Node.js in Pidora

So you have node.js running on a raspberry pi (if not see earlier post), I guess next you want to do some physical computing, and get some LEDs blinking.

In order to do physical computing, you need a library to access GPIO. Luckily, there is no shortage of   libraries for GPIO on npm. Without spending too much time, I have tried a few of them and for no particular reason, I have chosen to use wiring-pi.  wiring-pi is actually bindings to the WiringPi , a well known C library for GPIO.

Pidora actually includes WiringPi so you can actually start using it right away. It does come with a command line utility called gpio. However, the wiring-pi npm package does check out and compile its own copy of the library so if you do not already have it installed on your raspberry pi, do not worry.

Because wiring-pi needs git to retrieve WiringPi,  you need git to be available on your raspberry pi. First install it using

yum install git

Now you are ready to install wiring-pi

npm install wiring-pi

If you have followed my earlier post for installing node.js, you probably have a second node installation that came with pidora. In some cases, gyp conflicts with this obsolete one and installation of the wiring-pi may fail. To fix remove gyp and try to install wiring-pi again.

yum remove gyp
npm install wiring-pi

Since blinking LEDs were mentioned, here is a sample code that I have used, which is the example code from wiring-pi Github repository with a small change.

Read more →