Type name qualified by method name

[mlangkabel]

I'm currently expanding our source code analysis tool (which is currently available for C/C++ only) to support java as well. First I was using Javaparser but it didn't quite match our requirements. By accident I stumbled upon a comment where @ftomassetti mentioned this project. And I have to say: It's absolutely AWESOME! Thanks for making this!

Ok, now to my issue.I have the following code I want to analyze:

package x;

public class Foo
{
    public void test(float p)
    {
        class Bar
        {
            public float f;
        }
    }

    public void test(int p)
    {
        class Bar
        {
            public int f;
        }
    }
}

When using an AstVisitor that specifies the following visit method

@Override public void visit(final ClassOrInterfaceDeclaration n, final Void v)
{
    String name = JavaParserFacade.get(m_typeSolver).getTypeDeclaration(n).getQualifiedName();
    System.out.println(name);
    super.visit(n, v);
}

I get the following output:

x.Foo
x.Foo.Bar
x.Foo.Bar

Here the problem is that both Bar classes may define completely different types but share the same qualified name. Would it be possible to include the name of the method that acts as the class' context into the qualified name so that the output reads

x.Foo
x.Foo.test(float).Bar
x.Foo.test(int).Bar

instead?

[ftomassetti]

Those are Local Classes (http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.3).
While they are theoretically legal I never, ever, ever saw them being used in the millions of lines of Java code I saw. Typically people use anonymous classes, not local classes. In this case probably the fully qualified name does not make sense because they are not intended to be referred from outside the method where they are declared. What I would do is to verify if the node n of type ClassOrInterfaceDeclaration is contained in any method. If it is I would not use the Fully Qualified Name provided by java symbol solver but I would build it as you suggested. I would rather not build support for this in Java-Symbol-Solver because... it is very uncommon, bad, and most importantly I do not think I can provide a proper qualified name comparable to the ones built for other classes.

Thank you for your nice words, I hope this helps. If not please feel free to ask more questions!

[mlangkabel]

Thanks for the quick reply! In my case I'll need those names for visualization purposes. Even if it's very uncommon to encounter such a case one can never know what other programmers are up to ;)

So I'll follow your advice and stop name resolution when I hit a ClassOrInterfaceDeclaration to check whether or not it is declared inside the scope of a method.

You said that you do not think you can provide a proper qualified name comparable to the ones built for other classes. Can you elaborate a little on what is wrong with x.Foo.test(float).Bar and if you have any idea how to improve that name?

[ftomassetti]

The fact is simply that getQualifiedName is expected to return... the Qualified Name as intended for Java classes, not just any unique name I could produce. In this sense I would consider incorrect to return a name as the one you suggests, even if I understand is a good solution to produce a unique name for our goals: it is just not matching the definition of Qualified Name as most users would expect it

[mlangkabel]

Alright. Now I know what you mean. Let's keep the functionality that way!