Jean-Marc Desperrier wrote:
Of course Dehydra is much less required in that context, obviously the java Eclipse editor has a level of analyses of the java code that is quite up to part with what dehydra produces.
I have a feeling that the available tools for Java static analysis would be much easier to extend and develop, especially as gcj still has some problems working with newer Java code, AFAIK.
I was thinking about it for DXR, if some of your project code is in java, you'd want to be able to index it on the same DXR front-end, so it would be convenient to use the same tool chain, compiling the java with gcj.
It would only be of use if you could make the scripts identical, which roughly implies that you'd have to make the ASTs very similar, and I doubt that gcj would be that obliging. There's already enough distinctions in key parts (e.g., generics versus templates) that would make even type analysis differ.
Maybe they are also cases where after having developed some js analysis script, you want to run the same/similar analysis on the java part of your code, and not port it to completely different tool chain.
Java is not C or C++, nor is it JS. To a large degree, there are orthogonal concepts between the languages that needs to be expressed. The languages differ enough that using different tool chains would probably not be a bad idea.
But maybe also what makes the most sense in terms of development effort is for DXR to use the required equivalent tools from the Eclipse project, and convert their output to something it can understand.
This seems the preferable route to me. _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
