Why yet another tool for language recognition? Why not reusing open source and well-know libraries like ANTLR or JavaCC? This is These are the first question questions asked by any developer discovering SSLR. Of course this option was seriously studied and had big advantages but we decided to start from scratch for the following reasons:
- The SonarQube team is addicted to TDD addict , and we think that existing tools don't fit well with TDD as because they require some code generation, and doesnthey don't provide any simple and , quick way to unit test all part parts of a source code analyser like a parsing rule analyzer, such as parsing rules for instance.
- The SonarQube team is addicted to KISS addict , and so we think that a Java developer should be able to do anything from its his or her favorite IDE.
- This technology is also used We needed to analyse some legacy languages, like COBOL for instance , which require some very specific lexing and preprocessing features. Implementing those features with existing tools would have required us to fully master the implementation of those existing tools, and so we didn't benefit from a feel like we benefited from thier black box approach.
- In any case, the ultimate goal of SSLR is to provide a complete compiler front-end stack, which goes well beyond the parsing. Eventually, SSLR will sooner or later provide the required material ability to fully implement a:
- Symbolic table (currently in beta)
- Control flow graph
- Data flow analysis
- LLVM IR emitter
- Easy integration and use
- Just add a dependency on a jar file (or several jar jars, according to what you want to use : lexer/parser, xpath, common rules, symbol table, ...)
- No special step to add to the build process
- No "untouchable" generated code
- Everything in java
- Definition of grammar and lexer directly in code, using Java
- No break in IDE support (syntax highlighting, code navigation, refactoring, etc)
- Mature and production ready
- This technology is already used in production to analyse millions of COBOL, PL/SQL, Java, C, C#, ... lines of code
- Awesome performancesperformance
- Some common rules and basic metric computations available out-of-the-box
- XPath library to query the AST
- Toolkit to browse the AST of any source code and to evaluate XPath expressions on it
SSLR evolves pretty quickly and we hope to remove those these limitations sooner or later :
SSLR also comes with a MiniC language which has been created to easily and simply test all SSLR features. This MiniC language can be a good starting point for a beginner to understand how to implement/define the different mandatory layers to analyse a source code language: