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

当使用

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

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

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

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

好处无穷无尽。

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

龙目岛很棒，但是……

Lombok打破了注释处理的规则，因为它不生成新的源文件。这意味着它不能与其他注释处理器一起使用，如果它们期望getter /setter或其他任何存在的东西。

Annotation processing runs in a series of rounds. In each round, each one gets a turn to run. If any new java files are found after the round is completed, another round begins. In this way, the order of annotation processors doesn't matter if they only generate new files. Since lombok doesn't generate any new files, no new rounds are started so some AP that relies on lombok code don't run as expected. This was a huge source of pain for me while using mapstruct, and delombok-ing isn't a useful option since it destroys your line numbers in logs.

我最终破解了一个构建脚本，可以同时使用lombok和mapstruct。但我想放弃龙目岛，因为它太粗糙了——至少在这个项目中是这样。我一直在用龙目岛做其他东西。 更新到mapstruct+lombok:这两个库现在可以开箱即用。不过，对于其他注释处理器来说，这个问题仍然存在。

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

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

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

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

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

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

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

人们会抱怨缺少JavaDoc，

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

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

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

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

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

想要使用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的人也应该看看Scala。您在Lombok中发现的许多好想法都是Scala语言的一部分。

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

免责声明:我也喜欢Java !

我读了一些关于龙目岛的意见，实际上我在一些项目中使用它。

嗯，第一次接触龙目岛时，我的印象很差。几周后，我开始喜欢上它了。但几个月后，我发现了很多使用它的小问题。所以，我对龙目岛的最终印象并不是那么积极。

我这么想的理由是:

IDE plugin dependency. The IDE support for Lombok is through plugins. Even working good in most part of the time, you are always a hostage from this plugins to be maintained in the future releases of the IDEs and even the language version (Java 10+ will accelerate the development of the language). For example, I tried to update from Intellij IDEA 2017.3 to 2018.1 and I couldn't do that because there was some problem on the actual lombok plugin version and I needed to wait the plugin be updated... This also is a problem if you would like to use a more alternative IDE that don't have any Lombok plugin support. 'Find usages' problem.. Using Lombok you don't see the generated getter, setter, constructor, builder methods and etc. So, if you are planning to find out where these methods are being used in your project by your IDE, you can't do this only looking for the class that owns this hidden methods. So easy that the developers don't care to break the encapsulation. I know that it's not really a problem from Lombok. But I saw a bigger tendency from the developers to not control anymore what methods needs to be visible or not. So, many times they are just copying and pasting @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor annotations block without thinking what methods the class really need to be exposed. Builder Obssession ©. I invented this name (get off, Martin Fowler). Jokes apart, a Builder is so easy to create that even when a class have only two parameters the developers prefer to use @Builder instead of constructor or a static constructor method. Sometimes they even try to create a Builder inside the lombok Builder, creating weird situations like MyClass.builder().name("Name").build().create(). Barriers when refactoring. If you are using, for example, a @AllArgsConstructor and need to add one more parameter on the constructor, the IDE can't help you to add this extra parameter in all places (mostly, tests) that are instantiating the class. Mixing Lombok with concrete methods. You can't use Lombok in all scenarios to create a getter/setter/etc. So, you will see these two approaches mixed in your code. You get used to this after some time, but feels like a hack on the language.

就像另一个回答说的，如果您对Java的冗长感到愤怒，并使用Lombok来处理它，那么可以尝试Kotlin。