Repository files navigation

JavaSymbolSolver has been integrated inJavaParser: development will continue there!

We will work on current issues opened here, but all new issues should be opened in the JavaParser project

A Symbol Solver for Java built on top ofJavaParser from the same team of committers.

Currently the best source of documentation is inthis book

You can also read this article:

• Resolve method calls in Java code using the JavaSymbolSolver

JavaParser is a parser: given a source file it recognizes the different syntaticelement and produce an Abstract Syntax Tree (AST).

JavaSymbolSolver analyzes that AST and find the declarations connected to each element.

foo in the AST is just a name, JavaSymbolSolver can tell you if it refers to a parameter, a local variable, a field. It can also give you the type, tell you wherethe element has been defined and so on.

A Symbol Solver can associate a symbol in your code to its declaration. This is necessary to verify the type of an expression or to find the usage of a symbol (like a field or a local variable):

Consider this:

inta =0;voidfoo() {while (true) {Stringa ="hello!";Objectfoo =a +1;    }}

In the expressiona + 1 a parser (like JavaParser) is not able to tell us to which definition ofa we are referring to and consequently it cannot tell us the type ofa. The JavaSymbolSolver is able to do so.

Take a look atJavaParserFacade. For example you can use it to find the type of an expression:

Nodenode = <getthisnodebyparsingsourcecodewithJavaParser>TypetypeOfTheNode =JavaParserFacade.get(typeSolver).getType(node);

Easy, right?

The only configuration that it requires is part of theTypeSolver instance to pass it. ATypeSolver is the mechanism that is used to find the classes referenced in your code. For example your class could import or extend a given class and theTypeSolver will find it and build a model of it, later used to solve symbols. Basically there are fourTypeSolver:

• JavaParserTypeSolver: look for the type in a directory of source files
• JarTypeSolver: look for the type in a JAR file
• ReflectionTypeSolver: look for the type using reflection. This is needed because some classes are not available in any other way (for example theObject class). However this should be used exclusively for files in the java or javax packages
• CombinedTypeSolver: permits to combine several instances ofTypeSolvers

In the tests you can find an example of instantiatingTypeSolvers:

CombinedTypeSolvercombinedTypeSolver =newCombinedTypeSolver();combinedTypeSolver.add(newReflectionTypeSolver());combinedTypeSolver.add(newJavaParserTypeSolver(newFile("src/test/resources/javaparser_src/proper_source")));combinedTypeSolver.add(newJavaParserTypeSolver(newFile("src/test/resources/javaparser_src/generated")));

Typically to analize a project you want to create one instance ofJavaParserTypeSolver for each source directory, one instance ofJarTypeSolver for each dependency and oneReflectionTypeSolver then you can combine all of them in aCombinedTypeSolver and pass that around.

Tutorial on resolving method calls

We plan to write soon more examples and tutorials.

This project is more recent of JavaParser but it has been receiving some attention andit has been improving a lot recently.

It supports all features of Java 8 (lambdas, generic, type inference, etc.).Of course we expect some bugs to emerge from time to time but we are committed to help users solve them as soon as possible.

It has been also used in a commercial product fromCoati.

This code is available under the Apache License.

We use Travis to ensure our tests are passing all the time.

Thedev-files dir contains configurations for the Eclipse and the IDEA formatters (I took them from the JavaParser project, thanks guys!).

The project is structured in this way:

• We have nodes that wrap the JavaParser nodes (but can also wrap Javassist or JRE nodes)
• The nodes contain all the information of the AST
• Context classes contain the logic to solve methods, symbols and types in the respective context.
• Default fallback behavior: ask the parent context for help (so if a variable identifier cannot be solved inside a MethodContext the underlying ClassDeclarationContext is asked and maybe we find out that the identifier actually refers to a field.

A more detailed description of the architecture of the project is available inDesign.MD

We suggest that you use the local gradle wrapper within java-symbol-solver to execute gradle tasks. If you're working on a Linux or Mac system, this is./gradlew in the root directory of java-symbol-solver. On Windows, it'sgradlew.bat. When executing gradle tasks via your IDE, make sure to configure your IDE to also use this wrapper. If you use intelliJ, you need the "Use default Gradle wrapper" option in theIntelliJ Gradle settings.

The following tasks are most relevant:

• assemble: If you need to build the source code (the full command thus becomes.\gradlew assemble or.\gradlew.bat assemble depending on your Operating System).
• check: To run the tests
• check jacocoTestReport: To run the tests (if still necessary) and generate a test coverage report. This coverage report is then located at./java-symbol-solver-testing/build/jacocoHtml/index.html relative to your project root.
• install: To install the snapshot version of the project to your local maven repository, which can be useful to test changes you're working on against external projects.

In case you haven't worked with Gradle before, one thing of note is that Gradle will only perform tasks that are still relevant. Let's say you have subprojectsfoo andbar and you had previously compiled those. If you then make changes infoo and compile both again, onlyfoo will be compiled. You'll see in the Gradle output that the compile task ofbar is marked asUP-TO-DATE.

I would absolutely love every possible kind of contributions: if you have questions, ideas, need help or want to propose a change just open an issue. Pull-requests are greatly appreciated.

Thanks to Malte Langkabel, Ayman Abdelghany, Evan Rittenhouse, Rachel Pau, Pavel Eremeev, Simone Basso, Rafael Vargas, Christophe Creeten, Fred Lefévère-Laoide, and Genadz Batsyan for their contributions!

The project has been created byFederico Tomassetti and it is currently co-maintained by the JavaParser team. Core contributors are currentlyMalte Langkabel andPanayiotis Pastos