Fix generic type loss in AutowiredFieldIntoConstructorParameterVisitor (fixes #1005)

[dim-kod]

• Fixes issue AutowiredFieldIntoConstructorParameterVisitor loses generic type parameters #1005

What's changed?

AutowiredFieldIntoConstructorParameterVisitor now preserves generic type parameters when converting @Autowired fields to constructor parameters.

Both AddConstructorVisitor and AddConstructorParameterAndAssignment were using TypeUtils.asFullyQualified(type).getClassName() to render the field type in the generated constructor, which strips generics — so List<String> ends up as raw List.

The fix switches to TypeTree.toString(), which goes through JavaPrinter and gives you the full source-level type string. I also added addImportsForType/collectFullyQualifiedNames helpers to register type parameter FQNs with the JavaTemplate builder.

A second commit broadens the type guard from TypeUtils.asFullyQualified() == null to null || Primitive — this fixes a separate issue where array-typed fields like String[] a were silently skipped during constructor generation.

What's your motivation?

Any @Autowired field with a parameterized type ends up with a raw-type constructor parameter after the recipe runs, which produces compiler warnings and loses type safety.

Anything in particular you'd like reviewers to focus on?

• The TypeTree.toString() approach — it uses JavaPrinter.printTrimmed() under the hood and already handles all type forms (parameterized, wildcards, bounded wildcards, nested generics, arrays).
• The broadened type guard (Primitive check instead of asFullyQualified == null) — this intentionally lets JavaType.Array through.

Have you considered any alternatives or workarounds?

• A custom renderTypeSimple(JavaType) that recursively builds the simple-name type string from JavaType — works, but duplicates what TypeTree.toString() already does.
• TypeUtils.toString(JavaType) — produces fully qualified names (e.g. java.util.List<java.lang.String>), not source-level simple names, so it doesn't work for template strings.

Any additional context

Test coverage went from 11 to 22 tests. New tests cover:

• Generic types into new/existing/parameterized constructors (List<String>)
• Nested generics (Map<String, List<Integer>>)
• Wildcards: unbounded (List<?>), upper-bounded (List<? extends Number>), lower-bounded (List<? super Integer>)
• User-defined generic types across packages (MyService<MyConfig>)
• Array types (String[])
• @Autowired(required = false)
• Multiple annotations (@Autowired @Qualifier("myBean"))

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[dim-kod]

Hello @timtebeek, any updates?

[timtebeek]

Hi no just need some more time for a proper review and merge; but with Devoxx UK this week, and Code Remix Summit next week it can take a bit longer to run through. Thanks for the work and patience in seeing this through!

[dim-kod]

Understood, thanks.

[MBoegers]

Hey @dim-kod, thanks for your analysis on this one. I took your branch and evolved it by using more built-in utilities. Do you mind reviewing the result? #1037
If you are okay with the proposal you can close this PR.