Java Symbol Solver and Method Calls in PRIMITIVE

Java Symbol Solver and Method Calls in PRIMITIVE


Okay, we’re looking at Java Symbol Solver. It’s an open source project. What this project does is it lets us look at code from different sources (java code) and it analyzes it so that we can pull out different parts of it. What this lets us do is this lets us find relationships between different parts of the code. For example, if you were calling a method at one line of code, it would let you know where in the code it was calling it. So what we’re looking at is that I did a change to this project so that now in a lot of the places you would get the qualified name, so this is basically a unique name that lets us identify a piece of the code and we needed to get the class and the package name separately. We couldn’t get this from the qualified name directly so I wanted to add the getClassName() and getPackageName() so that we can access these. So to add these, I had to add this to one of the interfaces that all of these different Java, some of these different Java parser classes, inherit from. So I added it to type declaration because that’s where getQualifiedName() is and since I thought className and packageName were based on that I put it in type declaration. So there’s a lot of different classes that inherit from this: there’s different java parser classes but also places where the package and className don’t make sense such as in type parameters. So these didn’t end up getting implemented; so now I feel like I should have implemented it only for ReferenceTypeDeclaration. As you can see ReferenceTypeDeclaration extends TypeDeclaration and these are ReferenceType is anything that inherits from a Java object and – but if I show you TypeParameterDeclaration it’s basically if you’re using generics and then it says in the comment here if you had an E extends String then E would be the type parameter and these don’t really have package names and class names because they’re – we don’t really know what their type is it’s not well defined and the reason we wanted to use this symbol solver is so that we can find relationships between different parts of the code in our product. Right now, I’m looking at TypeParameterDeclaration and if I wanted to see every class that implemented this interface, I can’t do that right now but we wanted to add that so that I could click on this class and it would highlight all the different places that implemented this interface as one example of what we would use this for. I want to show the feature that this video has been talking about and this is that we want to show the references to other things in the code and right now we’re doing method calls so I’m going to go into this Helper class and we’re going to see that we’ve got getPackageName() is called inside containerName() and getClassName() is also called inside containerName() so you look at containerName() and you can see that yeah it’s used here. It’s not finding all the calls right now but so far it’s definitely been able to find a few of the calls so we’re still working on fixing it so that we can find everything. Here’s another class I can look at and here we will see solveType(). It’s deprecated, but you can see that it’s called in two other methods inside this class. It’s also called by itself, so that means it’s recursive: you can see it lighting itself up. Here we have toReferenceType, oh there’s a private method and it’s called in getSuperClass(), getInterfaces() and getAncestors() you’ll see that we’ve got toReferenceType() see inside a bunch of referenceType() so yeah Really hoping to get this working with all the calls.

3 thoughts on “Java Symbol Solver and Method Calls in PRIMITIVE”

  1. Of course you need VR to navigate Java code cause all it's verbose abstractions and ProxyAdapterFactorySingletonLayerImplementation don't fit on a normal screen.

Leave a Reply

Your email address will not be published. Required fields are marked *