如果你不知道，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问题。
在过去的一年里，我在几乎所有的项目中都使用了Lombok，但不幸的是，我把它移除了。在一开始，这是一种非常干净的开发方式，但为新团队成员设置开发环境并不是非常容易和直接的。头痛时，我就把它去掉了。但这是一个很好的工作，需要一些更简单的设置。
当我向我的团队展示项目时，他们的热情很高，所以我认为你不应该害怕团队的反应。
就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和Jackson CSV的问题，当我将我的对象(java bean)编组到CSV文件时，其中的列重复，然后我删除了Lombok的@Data注释，编组工作正常。
