I'd rank this as a nice to have.

Import wildcards are used throughout the library. This has two primary effects:

• Namespace disambiguation must be controlled by class names rather than just package names
• Understanding the code outside a java enabled IDE is difficult (say in the browser)

The first one has been dealt with by ensuring no names are repeated between packages and I can cope with that though it is not ideal.

The second point is a more critical annoyance when trying to browse the code on github itself or as text locally because you can't see what package a referenced class is from.

The import wildcards in the generated code can be removed (and ambiguous names handled correctly with full qualification when necessary) using a technique like this (taken from https://github.com/davidmoten/state-machine/blob/master/state-machine-generator/src/main/java/com/github/davidmoten/fsm/model/Generator.java):

Imports imports = new Imports();
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
PrintStream out = new PrintStream(bytes);
out.format("package %s;\n", pkg);
out.println();
out.println("<IMPORTS>");
out.println();
out.format("public interface %s<Id> extends %s<%s, Id>{\n", behaviourClassSimpleName(),
                    imports.add(EntityBehaviour.class), imports.add(clsName));
...
result.print(new String(bytes.toByteArray(StandardCharsets.UTF_8))
            .replace("<IMPORTS>", imports.importsAsString()));

In a nutshell, you write your imports last after registering all types in the Imports and the Imports object decides which classes need to be fully qualified (first in best dressed).

An easy option is after pasting generated code, use an IDE like Eclipse to organize imports across the project (right mouse on project - Source - Organize imports).

Got an opinion on this one @Cbales?