Lombok 的 val 推断的类型的复杂性是否有限制？答案

【问题标题】：Is there a limit to the complexity of a type to be inferred by Lombok's val?Lombok 的 val 推断的类型的复杂性是否有限制？
【发布时间】：2014-12-16 18:17:37
【问题描述】：

我有一个使用 jOOQ 编写的数据访问对象，它返回一个相当复杂的类型签名：

Map<Record, Result<Record14<String, Integer, String, String, String, String, String, String, Integer, String, Boolean, Boolean, Integer, Boolean>>> result = create....

我尝试用 Lombok 的 "val" 替换它

val result = create....

这在我从 Eclipse 运行/编译时有效...当我尝试在 Gradle 中编译时，我得到：

UpdatesDAO.java:307: error: incompatible types
            .fetchGroups(key);
                        ^
  required: val
  found: Map<Record,Result<Record14<String,Integer,String,String,String,String,String,String,Integer,String,Boolean,Boolean,Integer,Boolean>>>

谁能告诉我为什么它在 Gradle 中适用于更简单的类型，但不适用于更复杂的类型？我在同一个项目中还有其他地方看起来像：

val records = dao.getDatastoreById(id); // Returns a type of List<Datastore>

即使使用 Gradle 编译，它们也能正常工作……我错过了什么吗？

仅供参考：Lombok 版本 = 1.14.8，Gradle 版本 2.2.1

我已经尝试过 lombok==1.14.6，Gradle 版本 2.2.0

我也尝试过 Java 8 和 Java 7，包括 OpenJDK 和 Oracle JDK

【问题讨论】：

问题：为什么需要十四种泛型类型？这是代码的味道比什么都重要......
我想您将不得不与 jOOQ 人员以及他们如何进行数据库交互...不管它是否是代码异味，在编译时它会起作用几乎没有意义从 Eclipse 并且从 Gradle 编译时不起作用..
@Makoto：通常，这些类型只在 jOOQ 的 fluent API 的幕后使用，并由编译器推断

标签： gradle lombok

【解决方案1】：

答案是jOOQ的DSL和lombok的冲突。jOOQ的DSL有一个方法“val”，静态导入时会引起冲突：

import static org.jooq.impl.DSL.val;

如果您通过静态导入使用该“val”方法，它将破坏 lombok 的“val”实现。删除该静态导入并使用“DSL.val()”为我解决了这个问题。

【讨论】：