如果你不知道，Project Lombok帮助解决了Java的一些麻烦，比如用注释生成getter和setter，甚至是简单的JavaBean，比如用@Data生成。它真的可以帮助我，特别是在50个不同的事件对象中，你有多达7个不同的字段需要用getter来构造和隐藏。我可以用这个删除几乎一千行代码。
然而，我担心从长远来看，这将是一个后悔的决定。当我提到它的时候，火焰战争就会在##Java Freenode频道爆发，提供代码片段会让可能的助手感到困惑，人们会抱怨缺少JavaDoc，而未来的提交者可能无论如何都会删除它。我很享受积极的一面，但我担心消极的一面。
那么:在任何项目中使用Lombok安全吗?积极的影响抵得上消极的影响吗?
当前回答
我知道我迟到了，但我无法抗拒诱惑:喜欢Lombok的人也应该看看Scala。您在Lombok中发现的许多好想法都是Scala语言的一部分。
关于您的问题:让开发人员尝试Lombok肯定比尝试Scala更容易。试一试，如果他们喜欢，那就试试Scala。
免责声明:我也喜欢Java !
其他回答
听起来好像您已经认为Project Lombok为您提议的新项目提供了显著的技术优势。(首先要澄清的是，我对龙目岛项目没有特别的看法，无论如何。)
在某些项目(开源或其他方式)中使用Project Lombok(或任何其他改变游戏规则的技术)之前，您需要确保项目涉众同意这一点。这包括开发人员和任何重要的用户(例如，正式或非正式的赞助商)。
你提到了这些潜在的问题:
当我提到它时，火焰战争将在##Java Freenode频道爆发，
一件容易的事。忽略/不要参与战火，或者只是避免提及龙目岛。
提供代码片段会让可能的助手感到困惑，
如果项目策略是使用Lombok，那么可能的助手将需要习惯它。
人们会抱怨缺少JavaDoc，
这是他们的问题。心智正常的人都不会把自己组织的源代码/文档规则死板地应用到第三方开源软件上。项目团队应该可以自由地设置与所使用的技术相适应的项目源代码/文档标准。
(跟进- Lombok开发人员认识到，不为合成的getter和setter方法生成javadoc注释是一个问题。如果这是您的项目的主要问题，那么另一种选择是创建并提交Lombok补丁来解决这个问题。)
未来的提交者可能会把它全部删除。
那没开!如果商定的项目策略是使用Lombok，那么毫无理由地去Lombok代码的提交者应该受到惩罚，如果有必要，他们的提交权将被撤销。
当然，这是假设你已经得到了涉众的支持……包括开发者。它还假定你已经准备好为自己的理由辩护，并适当地处理不可避免的不同声音。
还有长期维护的风险。首先，我建议你阅读一下Lombok的实际工作原理，比如这里有一些来自开发人员的回答。
官方网站还列出了一些缺点，包括Reinier Zwitserloot的这句话:
It's a total hack. Using non-public API. Presumptuous casting (knowing that an annotation processor running in javac will get an instance of JavacAnnotationProcessor, which is the internal implementation of AnnotationProcessor (an interface), which so happens to have a couple of extra methods that are used to get at the live AST). On eclipse, it's arguably worse (and yet more robust) - a java agent is used to inject code into the eclipse grammar and parser class, which is of course entirely non-public API and totally off limits. If you could do what lombok does with standard API, I would have done it that way, but you can't. Still, for what its worth, I developed the eclipse plugin for eclipse v3.5 running on java 1.6, and without making any changes it worked on eclipse v3.4 running on java 1.5 as well, so it's not completely fragile.
总之，虽然Lombok可以节省一些开发时间，但如果有一个不向后兼容的javac更新(例如漏洞缓解)，Lombok可能会让您陷入旧版本的Java，而开发人员则会争先恐后地更新他们对那些内部api的使用。这是否是一个严重的风险显然取决于项目。
我还没有尝试使用Lombok -它是/是我清单上的下一个，但听起来Java 8给它带来了很大的问题，补救工作在一周前仍在进行中。我的来源是https://code.google.com/p/projectlombok/issues/detail?id=451。
继续使用Lombok吧，如果有必要，您可以在之后“delombok”您的代码http://projectlombok.org/features/delombok.html
我知道我迟到了，但我无法抗拒诱惑:喜欢Lombok的人也应该看看Scala。您在Lombok中发现的许多好想法都是Scala语言的一部分。
关于您的问题:让开发人员尝试Lombok肯定比尝试Scala更容易。试一试，如果他们喜欢，那就试试Scala。
免责声明:我也喜欢Java !
