Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Type analisys for JSDT

Thanks Eugene for bringing this up.
I think we have several choices with inference, and probably the list below does not cover all. Here is my quick thoughts.

1. Tern.js
tern.js is the most obvious choice for inference. It has the advantage that it has an existing community, it is familiar to is it is used by Orion. The boundary crossings between JS/Java is an issue but I think we can probably improve it switching our
JS runtime if we feel the need.

We also need to think about our integration strategy. We can try to integrate tern.js output directly into JSDT’s AST or use the same approach that has which integrates on IDE features level such as providing code completion implementations that directly query tern and bypass

2. Implement own inference.
We can do this either with a project like TAJS or from scratch ourselves(not preferred). However inference is only half of the problem. We also need to have an efficient way to store and query the information. Per JSDT bugzilla, we already know that the borrowed JDT index/search mechanism did not really work for JSDT. I hear good things about the new indexer [1] but it needs to be tried out in JS context. I think combining TAJS with the new indexer could be a good experiment to see the performance on large

Personally, I think what TAJS can do is really powerful and unique. I think we can write a converter that can convert JSDT’s DOM AST to one that TAJS can consume for a quick solution. I think it does make sense to collaborate and see if we can come up with a solution
that scales and provides an integrated experience.


3. Another alternate is typescript language tools but technically it is similar to tern.js with limitations. I think with this option we have no way to avoid double parsing, and looks like getting information that can be
incorporated to our AST is not possible.


On 31 Mar 2016, at 10:49, Eugene Melekhov wrote:

Hi all,

I've been thinking about missing code assist, search etc caused by loosing type inference after switch to new parser. First obvious candidate for type inference engine is widely used Tern [1] of course. However using it has some drawbacks like double parsing, JS->Java->JS data transfer etc. I thought about writing something similar based on Tern's idea, but reading some papers on the subject of JIT/static type analysis I stumbled upon very interesting project
TAJS: Type Analyzer for JavaScript [2].

It has the Eclipse plugin and provides lot of useful type information. It seems to be a great candidate for the JSDT's inference engine. Even though it's possible to use it as is (just as existing plugin) I believe both TAJS and JSDT may
benefit from more tight integration. I mean common AST for example.

TAJS uses the google closure compiler parser and thus its AST tree format. We use esprima and convert it to our AST. It's possible either come to some unified format or use google's or use JSDT's.

I mentioned closure compiler parser some time ago, and its usage in one more projects makes me think about it again.

So, what do you think about possible cooperation with TAJS to our mutual benefit? :-)


Eugene Melekhov

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

Back to the top