bug: <> dropped from constructor calls to generic types (noclasspath)

[slarse]

Hi!

I've found another noclasspath bug. It's not too critical, but it affects my use case a bit horribly. In any case, whenever there is a constructor call to a generic type A, and the actual type arguments are omitted, then Spoon doesn't actually pick up the type arguments iff A is not on the classpath. Here's an example:

java.util.ArrayList<Integer> list = new ArrayList<>();
A<Integer> a = new A<>();

In the snippet above, the type access in new ArrayList<>(); will have an implicit Integer type argument. However, the type access in new A<>(); will not. Just parsing and pretty-printing the above will yield the following.

java.util.ArrayList<Integer> list = new ArrayList<>();
A<Integer> a = new A();

Note how the type access in new A() suddenly is raw.

This is only a problem under these specific conditions:

1. The actual type arguments are omitted in the source code.
2. The generic type that's specialized is not available on the classpath OR the constructor call is contained in a context where the type arguments cannot be inferred, such as inside of a call to an unresolved method.

In summary, this only affects noclasspath mode when using non-stdlib generic types, or using non-stdlib methods that have specialized generic types as arguments. The problem is that the JDT node doesn't actually have the type information about the type arguments that should be inferred from the context.

I'll have a PR up with a test case later today, but I've only been able to partially solve the issue.

[slarse]

Oh, right, in some cases it is impossible to infer the type arguments in noclasspath mode. For example, something like this:

someMethod(new A<>());

If someMethod is not available, then there's no way to infer the type arguments. Perhaps it would make sense to have a special, constant type for omitted type arguments, such that at least it's evident that the <> were actually in the source code, even if the exact type argument(s) can't be determined?

[slarse]

Turns out it breaks in a different place when the generic type is resolved, but it's used in an unresolved method/constructor. Like this:

someMethod(new java.util.ArrayList<>());