最近，我与jOOQ的早期客户Ergon的 Sebastian Gruber进行了非常有趣的讨论，我们与之保持了密切联系。 与Sebastian交谈使我们的工程团队得出结论，认为我们应该完全重写jOOQ API。 现在，我们已经有很多用于各种用途的泛型，例如

• 列类型的泛型，例如

  interface Field<T> { ... }
  Field<String> field = BOOK.TITLE;

• 表类型的泛型，例如

  interface Table<R extends Record> { ... }
  Table<BookRecord> books = BOOK;

• 同时使用<T>和<R>组合泛型
• … 以及更多

有时，您只是无法预测两年后您的类和接口将需要多少种通用类型，而Java的问题是：您只能一次生成一个类。 假设您一直都有这样的类型：

class Foo {}

现在您知道，您需要两个泛型类型参数现在 ：

// Still compatible
class Foo<Bar, Baz> {}

这样就可以了，所有现有的客户端代码仍将编译，并带有原始类型警告。 但是，一旦发布了Foo<Bar, Baz> ，就不能再向其中添加或删除类型变量。 每次修改都会破坏客户端代码！

// Breaking change
class Foo<Bar, Baz, Fizz> {}

解决方案：泛型类型

我们不想给我们的客户带来负担，这是向后不兼容的沉重负担。 这就是为什么我们现在发布具有新功能的下一个jOOQ版本 ，我们称之为泛型泛型类型 。 它是如何工作的？ 这简单。 我们从最好的数据库设计人员那里学习，他们一直以来都在使用通用列类型。 在SQL中，如果遇到这种问题，您只需写：

CREATE TABLE foo (bar int,baz int,fizz int,generic_1 varchar(4000),generic_2 varchar(4000),generic_3 varchar(4000),generic_4 varchar(4000),-- [...]
);

现在，您的SQL模式在以后的时代都是安全的。 我们将在Java中执行相同的操作：

class Foo<Bar, Baz, Fizz,Generic1,Generic2,Generic3,Generic4,// [...]
> {}

因此，我们将所有类型泛型化为具有256个泛型类型参数。 256是MS Access为可能的列数选择的明智限制。 这样，我们的客户只需要一次升级到新版本的jOOQ，从那时起，将永远保证通用类型的向后兼容性。

编码愉快！

翻译自: https://www.javacodegeeks.com/2015/04/dont-be-fooled-by-generics-and-backwards-compatibility-use-generic-generic-types.html