Full identifier qualification in generated code when <globalObjectReferences> is turned off

[lukaseder]

When <globalObjectReferences/> is turned off, generated code in getPrimaryKey(), getIndexes(), etc. fully qualifies identifiers instead of re-using existing imports.

For example:

    @Override
    public UniqueKey<GlobalObjectReferencesFalse_1PkRecord> getPrimaryKey() {
        return Internal.createUniqueKey(org.jooq.codegen.test.globalobjectreferencesfalse.db.tables.GlobalObjectReferencesFalse_1Pk.GLOBAL_OBJECT_REFERENCES_FALSE_1_PK, "CONSTRAINT_B", new TableField[] { org.jooq.codegen.test.globalobjectreferencesfalse.db.tables.GlobalObjectReferencesFalse_1Pk.GLOBAL_OBJECT_REFERENCES_FALSE_1_PK.I }, true);
    }
    @Override
    public List<UniqueKey<GlobalObjectReferencesFalse_1PkRecord>> getKeys() {
        return Arrays.<UniqueKey<GlobalObjectReferencesFalse_1PkRecord>>asList(
              Internal.createUniqueKey(org.jooq.codegen.test.globalobjectreferencesfalse.db.tables.GlobalObjectReferencesFalse_1Pk.GLOBAL_OBJECT_REFERENCES_FALSE_1_PK, "CONSTRAINT_B", new TableField[] { org.jooq.codegen.test.globalobjectreferencesfalse.db.tables.GlobalObjectReferencesFalse_1Pk.GLOBAL_OBJECT_REFERENCES_FALSE_1_PK.I }, true)
        );
    }

[lukaseder]

The reason these identifiers are not shortened is because their referenced class name is the same as the containing class name:

jOOQ/jOOQ-codegen/src/main/java/org/jooq/codegen/JavaWriter.java

Line 252 in f1568d4

if (!className.equals(unqualifiedType) &&

This check protects against imports of different classes that go by the same name as the class currently being generated. An example scenario is that a generator strategy omits the Record suffix on records, which leads to record classes having the same name as table classes.

We could obviously improve this check to compare fully qualified type names, and apply only when the class name is the same, but not the fully qualified class name.

[lukaseder]

The current JavaWriter doesn't know the package name it generates. It doesn't even know the class name it generates, the class name is derived from the file name by convention. A clean fix is not possible, backwards compatibly.

But we have JavaGenerator.printPackage, which could call new JavaWriter API that communicates the package name to the write after having started writing to the file. Not very clean but it would work for almost all cases, as the package statement is required to be at the top of a compilation unit in Java.

[lukaseder]

Fixed in jOOQ 3.13.0. With these delicate code generator changes, there's always a very slight risk of introducing an edge case regression that leads to new compilation errors. Given the cosmetic nature of the bug, I will thus not backport the fix to 3.12.