Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT Parser

On 11 Mar 2016, at 11:34, Eugene Melekhov wrote:


Thanks for prompt reply. I read your post about benchmarking with pleasure. I've never heard about Shift parser and it looks very promising. I took a quick glimpse at sources and imho they are really smart, neat and "clean" :-). Great job.

BTW, they implemented location info, so the only missing part is error recovery / tolerant parsing. Speaking of which, it seems that with their two-phase parser recovery is only required at syntax level. "Semantic/Early errors" are handled separately, which on the one hand probably makes recovery easier to implement and on the other hand gives client
some freedom to use second pass only if needed, and speed of course...

I ran your benchmarks (w/o node. I didn't want to bother with configuring node benchmark properly on my Windows box).
Below are my results:

# Run complete. Total time: 01:26:54

Benchmark                           Mode  Cnt   Score   Error  Units
AcornWithJ2V8.testAngular125       thrpt  200  10,176 ? 0,045  ops/s
AcornWithJ2V8.testJQM142           thrpt  200   7,755 ? 0,023  ops/s
AcornWithNashorn.testAngular125    thrpt  200  11,398 ? 0,310  ops/s
AcornWithNashorn.testJQM142        thrpt  200   8,793 ? 0,257  ops/s
EsprimaWithJ2V8.testAngular125     thrpt  200  11,393 ? 0,135  ops/s
EsprimaWithJ2V8.testJQM142         thrpt  200   9,432 ? 0,029  ops/s
EsprimaWithNashorn.testAngular125  thrpt  200  15,459 ? 0,130  ops/s
EsprimaWithNashorn.testJQM142      thrpt  200  15,223 ? 0,110  ops/s
NashornParser.testAngular125       thrpt  200  41,306 ? 0,208  ops/s
NashornParser.testJQM142           thrpt  200  37,744 ? 0,104  ops/s
ShiftJava.testAngular125           thrpt  200  74,734 ? 0,203  ops/s
ShiftJava.testJQM142               thrpt  200  76,934 ? 0,413  ops/s

As you might notice I've added NashornParser (native JVM) test (sample borrowed from Nashorn sources). And it performs
quite well, not as good as Shift, but not bad.

This is excellent can you send a pull request to that repo so that we have those tests always handy.

So, according to the benchmarks Esprima with Nashorn and Nashorn "native JVM" parser are good options, but in the long run I'd prefer to use Shift because it's fast, it's nice Java etc. It might worth trying to add error recovery to it if
it's not that hard....

Yes, shift was my early favourite as well, however not getting any response to my requests and seeing shift.js being active while was dormant did not really help. Also (and its AST model) is not really adopted by anyone else. At the end, we were not looking for a parser to maintain ourselves ( we had that already). But I agree, we can switch to if we can feel more confident about the future of the project.

I've managed to obtain, compile, run/test latest code that you've mentioned; I have more or less normal working configuration and can do something useful. So, what would you suggest to look at? Some small/relatively easy task that would allow me to get acquainted with code and bring some value? I thought that something like unit tests for particular
parser/ast related parts would be a good start. What do you think?

That would be fantastic and I have the perfect candidate. Please take a look at [1]. It is a small enough task but will
get you familiar with the AST quickly :)

[1] >


Hi Eugene,

Yes, help is definitely is definitely needed and appreciated.

There is an ongoing work around JavaScript parser and you can see the
latest code at
At this time we are trying to introduce the esprima parser by running it
with nashorn. We will
be using the parser to generate what is known as DOM AST or external AST
and retire the old/internal AST that is tightly
couple to the current parser.

We did consider several options for a replacement parser [1]. I have
also looked at mending the JDT compiler based parser.
Even though it is possible to fix the current parser as you have said
with a few good alternates around I do not think
the effort is worth it.

I am aware of the JEP 236, and we are architecting the new parser in
such a way that we can replace it relatively painless
in the future. The replacement can easily be Nashorn’s parser provided
that it supports the latest Ecmascript specification.

Please let me know if you have any further questions. I also recommend
reading our recently revamped contributing wiki [2].


On 10 Mar 2016, at 2:51, Eugene Melekhov wrote:

Hi all,

I'd like to help JSDT and I believe that Compiler/Parser is one of the
places that needs change. Does anyone works on
it? Are there any new implementation ideas?

I see that at the moment it's based on the JDT compiler code base and
thus depends on jikes parser generator. Even
though using generator is OK in general it seems to me that
maintaining and developing such parser is harder then
maintaining just hand-written one; especially when up-to-date
open-source JS parsers are available at the moment.

I looked at the Nashorn sources and they are quite clean, readable and
maintainable, though I don't have any performance
comparison results. There is no Nashorn's public parser API yet, but
JEP 236 addresses this issue and it will be
available in Java 9.

What do you think of using Nashorn parser in JSDT?


Eugene Melekhov

wtp-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
wtp-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Eugene Melekhov

wtp-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top