Consider renaming / aliasing org.jooq.Record

[lukaseder]

Starting with more recent JDKs, we'll be in an unfortunate situation where one of our main types org.jooq.Record will be in conflict with a new type from the java.lang package: java.lang.Record. The types in java.lang are auto-imported in Java, which leads to even more confusion.

So far, we haven't had this situation. Maybe, it is not a problem - this issue is to collect feedback from the community to assess whether we need to take action. There are several options:

• Rename the type (and subtypes) incompatibly. We could call it Rec (and Rec1, Rec2, UpdatableRec, etc.). This is thorough, but not very desireable.
• Add a super type Rec with Record <: Rec that users could reference instead. All the Record API would go to Rec. All the receiving ends of the jOOQ API would use Rec instead of Record (e.g. Result<R extends Rec>). Methods would continue to return the more specific Record. This would be mostly source compatible (probably, some occasional invariance would get in the way), but a bit confusing.
• Add a sub type Rec with Rec <: Record that users could reference instead. All the Record API would remain in Record. All the receiving ends of jOOQ API would continue using Record. Methods would now return Rec instead. This would be mostly source compatible (probably, some occasional invariance would get in the way), and perhaps a bit less confusing.

Perhaps, other options exist.

[lihonosov]

yeah, my build failed with java 14 :(

Error:(150,19) java: reference to Record is ambiguous

Reference to 'Record' is ambiguous, both 'org.jooq.Record' and 'java.lang.Record' match

Everything works with explicit import:

import org.jooq.Record;

[lukaseder]

Such is life.

Very rarely, the JDK adds stuff to the java.lang package, which can break user code when users use * imports. Typically, this isn't the case as IDEs tend to expand these imports, and they keep learning about such changes, including this one. I think this is now no longer a problem in IntelliJ? Also, as var becomes more popular, it might become less of a problem as users will assign their records to a var local variable rather than declaring it explicitly.

Renaming such an ubiquitous type is almost impossible in jOOQ. It would break every piece of jOOQ code out there. This problem here can be solved quickly after upgrading to Java 14+ by using an IDE to re-organise imports.

If Java had type aliases, then a solution would be possible. But unfortunately, it doesn't.