我正在为新的一年提出性能目标,并且我认为设定一个减少代码库大小的目标会很有趣,尤其是样板文件。为了解决这个问题,我想出的一项措施是使用Project Lombok使 bean 尽可能短。但是我习惯于忽略新软件和方法的缺点,所以我依赖于 Stack Overflow 社区:谁能告诉我为什么 Lombok 是个坏主意?
8 回答
Lombok 的一个限制是它与 java 编译器密切相关。由于注解处理器 API 只允许在编译期间创建新文件(而不是修改现有文件),lombok 使用该 API 作为修改 java 编译器的入口点。不幸的是,编译器的这些修改大量使用了非公共 API。使用 lombok 可能是个好主意,但您必须意识到升级编译器可能会破坏您的代码。概率很低,但我总是对使用非公共 API 感到不舒服。
在我看来,“Java+Lombok”中的源代码不再是 Java 源代码。我认为它与多年前 Borland 公司在他们的 Borland C++ Builder IDE for VCL 中所做的类似——他们在 C++ 代码中引入了“属性”,有效地引入了某种不再是 C++ 的新编程语言(不是 C++ 意义上的C++ 语言标准)。使用“Java+Lombok”的源不是 Java 语言规范意义上的有效源。此外,我认为注释并非旨在影响语言语义。
一个主要的缺点是 IDE 支持。由于 Lombok 实际上并不是一种语言更改,而且您的 IDE 只支持 java,因此您需要一个支持 Lombok 的 IDE 才能正常工作。到目前为止,这只是包括 Eclipse 和 IntelliJ 的 Eclipse。如果您使用 eclipse 可能没问题,但请记住,您也在为未来的开发人员做出决定。
我建议您考虑将您的一些代码移动到一种不太正式的语言中,例如 groovy。我们已经成功地将我们的一些业务逻辑和模型转移到了 groovy 中,并且运行起来非常顺利。
像 Lombok 这样的东西的一个潜在缺点是,由于“缺少”setter/getter,源工具可能无法“识别”结果对象的赋予它“bean”品质的方面,因为这些品质只体现在编译的类中。
另一个缺点是它是工具链中的又一个“黑魔法”。幸运的是,它似乎是一个相当良性的部分(我没有使用它),它发生在编译时而不是运行时的事实实际上是一种祝福(恕我直言)。但是,如果没有项目,您将无法重用或共享您的代码,因为它会将工件添加到您的代码库中。因此,虽然编译的类文件可能是“POJO”,但我认为您的源代码不是 POJO。
这些都不是严重的缺点,而只是需要注意的方面。
是第三方库,有些开发者不太了解。
IDE 应该支持注解处理(IDEA 和 Eclipse 有插件)。
如上所述,您的代码将没有 getter/setter。它会导致声纳/检查样式违规。
在我看来,Project Lombok 最明显的风险是,当您决定使用 lombok 时,您还决定处理您代码的其他所有人都使用 lombok。这是对所有库的正确陈述,但 Lombok 的特殊之处在于它是构建时依赖项,并且您的 IDE 需要插件来弄清楚发生了什么。这意味着任何有理由接触您的代码的人。有人试图调试奇怪的行为等)需要知道如何设置它以及它是如何工作的。这可能有点令人沮丧。
正如用户@Jcs在另一个答案中指出的那样,我想添加更多。
在我们的项目中,我们使用 mapstruct 来生成映射器类,在编译代码之前,使用 mvn generate-sources 命令,这是在进程阶段使用 maven 处理器插件完成的。
project lombok 在编译阶段在类文件中添加 getter/setter 的字节码。
由于进程阶段是在编译之前执行的,因此它发现类中没有可用的 getter/setter。
有一些变通方法可用于执行多个编译阶段。有关更多详细信息,请参阅此git hub 票证。
注意:我正在使用 Spring 的 STS ide,它由 lombok 支持:)
添加到其他响应。
不使用它的主要原因是record
在 Java 14 中作为实验性特性添加了一个新关键字。Java 16records
推出了预览版,这将使 Lombok 项目在大多数情况下过时。
由于 Java 14 能够编写:
record Book(String title, String author, String isbn);
它可以自动访问构造函数、getter/setter、hashCode、equals 和 toString 方法,而无需任何注释。