如果你不知道,Project Lombok帮助解决了Java的一些麻烦,比如用注释生成getter和setter,甚至是简单的JavaBean,比如用@Data生成。它真的可以帮助我,特别是在50个不同的事件对象中,你有多达7个不同的字段需要用getter来构造和隐藏。我可以用这个删除几乎一千行代码。

然而,我担心从长远来看,这将是一个后悔的决定。当我提到它的时候,火焰战争就会在##Java Freenode频道爆发,提供代码片段会让可能的助手感到困惑,人们会抱怨缺少JavaDoc,而未来的提交者可能无论如何都会删除它。我很享受积极的一面,但我担心消极的一面。

那么:在任何项目中使用Lombok安全吗?积极的影响抵得上消极的影响吗?


当前回答

我个人(因此也是主观上)发现,与IDE/自己实现的复杂方法(如hashcode & equals)相比,使用Lombok使我的代码更能表达我想要实现的目标。

当使用

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

与任何IDE/自己的实现相比,保持Equals & HashCode一致并跟踪哪些字段被求值要容易得多。当您仍然定期添加/删除字段时,这一点尤其正确。

@ToString注释及其参数也是如此,它们清楚地传达了所期望的行为,包括包含/排除字段、getter的使用或字段访问,以及是否调用super.toString()。

同样,通过使用@Getter或@Setter(AccessLevel.NONE)注释整个类(并可选择覆盖任何发散的方法),可以立即清楚哪些方法将可用于字段。

好处无穷无尽。

在我看来,这不是关于减少代码,而是关于清楚地传达您想要实现的目标,而不是必须从Javadoc或实现中找到答案。减少的代码只是使它更容易发现任何发散方法实现。

其他回答

想要使用lombok的@ToString,但很快在Intellij IDEA中重新构建项目时遇到了随机编译错误。在增量编译成功完成之前,必须多次点击编译。

使用Intellij IDEA 12.1.6和13.0在jdk 1.6.0_39和1.6.0_45下尝试了lombok 1.12.2和0.9.3,没有任何lombok插件。

不得不手动从delomboked源复制生成的方法,并将lombok搁置,直到更好的时机。

更新

只有启用并行编译时才会出现这个问题。

提交一个问题: https://github.com/rzwitserloot/lombok/issues/648

更新

mplushnikov于2016年1月30日评论道: 更新版本的Intellij 不再有这样的问题了。我想这里可以关了。

更新

如果可能的话,我强烈建议从Java+Lombok切换到Kotlin。 因为它已经从头开始解决了Lombok试图解决的所有Java问题。

当我向我的团队展示项目时,他们的热情很高,所以我认为你不应该害怕团队的反应。

就ROI而言,集成它很简单,并且不需要对其基本形式进行代码更改。(只需向类中添加一个注释) 最后,如果您改变了主意,您可以运行unlombok,或让IDE创建这些setter、getter和ctor(我认为一旦他们看到您的pojo变得多么清晰,就没有人会要求它们了)

听起来好像您已经认为Project Lombok为您提议的新项目提供了显著的技术优势。(首先要澄清的是,我对龙目岛项目没有特别的看法,无论如何。)

在某些项目(开源或其他方式)中使用Project Lombok(或任何其他改变游戏规则的技术)之前,您需要确保项目涉众同意这一点。这包括开发人员和任何重要的用户(例如,正式或非正式的赞助商)。

你提到了这些潜在的问题:

当我提到它时,火焰战争将在##Java Freenode频道爆发,

一件容易的事。忽略/不要参与战火,或者只是避免提及龙目岛。

提供代码片段会让可能的助手感到困惑,

如果项目策略是使用Lombok,那么可能的助手将需要习惯它。

人们会抱怨缺少JavaDoc,

这是他们的问题。心智正常的人都不会把自己组织的源代码/文档规则死板地应用到第三方开源软件上。项目团队应该可以自由地设置与所使用的技术相适应的项目源代码/文档标准。

(跟进- Lombok开发人员认识到,不为合成的getter和setter方法生成javadoc注释是一个问题。如果这是您的项目的主要问题,那么另一种选择是创建并提交Lombok补丁来解决这个问题。)

未来的提交者可能会把它全部删除。

那没开!如果商定的项目策略是使用Lombok,那么毫无理由地去Lombok代码的提交者应该受到惩罚,如果有必要,他们的提交权将被撤销。

当然,这是假设你已经得到了涉众的支持……包括开发者。它还假定你已经准备好为自己的理由辩护,并适当地处理不可避免的不同声音。

在过去的一年里,我在几乎所有的项目中都使用了Lombok,但不幸的是,我把它移除了。在一开始,这是一种非常干净的开发方式,但为新团队成员设置开发环境并不是非常容易和直接的。头痛时,我就把它去掉了。但这是一个很好的工作,需要一些更简单的设置。

我知道我迟到了,但我无法抗拒诱惑:喜欢Lombok的人也应该看看Scala。您在Lombok中发现的许多好想法都是Scala语言的一部分。

关于您的问题:让开发人员尝试Lombok肯定比尝试Scala更容易。试一试,如果他们喜欢,那就试试Scala。

免责声明:我也喜欢Java !