Stub classes are falsely contained in a model method

[LABSARI]

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.

[anneetien]

@soufyane, you are on Mac, or you have also this issue on Linux? Anne

…

Le 8 déc. 2022 à 10:50, Soufyane Labsari ***@***.***> a écrit : 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. — Reply to this email directly, view it on GitHub <#56>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7WQZLYUTC5F6ENQYISG3WMGVNJANCNFSM6AAAAAASX5LUIE>. You are receiving this because you are subscribed to this thread.

[NicolasAnquetil]

I reproduced the error on Linux.

[badetitou]

So, if an entity is a stub, it should not have typeContainer? we agree?

[anneetien]

It can have a parentPackage (For example java.util.Map) I don’t know for typeContainer.

…

Le 8 déc. 2022 à 12:02, Benoît Verhaeghe ***@***.***> a écrit : So, if an entity is a stub, it should not have typeContainer? we agree? — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7WQ2CPRCVKJP47HPABTTWMG525ANCNFSM6AAAAAASX5LUIE>. You are receiving this because you commented.

[NicolasAnquetil]

It can have a typeContainer, but a stub cannot be contained in a non stub (which is the case here)

[LABSARI]

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.

[NicolasAnquetil]

1. 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
2. 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