如果你不知道,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或实现中找到答案。减少的代码只是使它更容易发现任何发散方法实现。

其他回答

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

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

我对Lombok的看法是,它只是为编写样板Java代码提供了快捷方式。 当涉及到使用快捷方式来编写Java代码时,我会依赖IDE提供的这些特性——就像在Eclipse中一样,我们可以转到Source > Generate Getters and Setters菜单来生成getter和setter。 我不会依赖Lombok这样的库:

It pollutes your code with an indirection layer of alternative syntax (read @Getter, @Setter, etc. annotations). Rather than learning an alternative syntax for Java, I would switch to any other language that natively provides Lombok like syntax. Lombok requires the use of a Lombok supported IDE to work with your code. This dependency introduces a considerable risk for any non-trivial project. Does the open source Lombok project have enough resources to keep providing support for different versions of a wide range of Java IDE's available? Does the open source Lombok project have enough resources to keep providing support for newer versions of Java that will be coming in future? I also feel nervous that Lombok may introduce compatibility issues with widely used frameworks/libraries (like Spring, Hibernate, Jackson, JUnit, Mockito) that work with your byte code at runtime.

总而言之,我不喜欢用龙目岛来“调味”我的爪哇。

继续使用Lombok吧,如果有必要,您可以在之后“delombok”您的代码http://projectlombok.org/features/delombok.html

我还没有尝试使用Lombok -它是/是我清单上的下一个,但听起来Java 8给它带来了很大的问题,补救工作在一周前仍在进行中。我的来源是https://code.google.com/p/projectlombok/issues/detail?id=451。

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

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

免责声明:我也喜欢Java !