Stub classes are falsely contained in a model method
LABSARI opened this issue · 7 comments
public class A {
public List<Integer> getList() {
List<Integer> list = new ArrayList<Integer>();
return list;
}
}In the generated model of above class, we have List and ArrayList contained in the method getList().
The typeContainer of List and ArrayList is the method getList(). It should not.
There are no class definitions in that method, just references.
I reproduced the error on Linux.
So, if an entity is a stub, it should not have typeContainer? we agree?
It can have a typeContainer, but a stub cannot be contained in a non stub (which is the case here)
The problem is Verveine cannot resolve bindings in the AST of some classes because they contain compilation errors or dependency errors. When a reference to a class is not resolved, VerveineJ creates a new class and puts it in the current context (here the context is the method). That is why ArrayList and List are contained in the method getList(). There are dependency errors in that file since List and ArrayList are not imported.
VerveineJ takes as input a folder containing the sources of a project and it parses ALL Java files in that folder sub-hierarchy. Some of these Java files may not be used anymore and ignored in the build of the project. There are other scenarios leading to such errors in the resulting model, all linked with unresolved bindings in the AST.
VerveineJ should do some checks on the project before parsing.
- We should be ready to accept source files that have "compilation errors". Sometimes you don't have all the necessary dependencies and you still want to have a model, even if it is not perfect.
Ideally VerveineJ would detect the problem and warn the user - About "dead files" (source files that are not used in the build) we could have an option to explicitly ignore them, but we could as well just ask the user to remove them from the source path ...
The real problem seems that the user is not aware that they are dead files