今天刚开始使用Lombok。到目前为止，我喜欢它，但是我没有提到的一个缺点是重构支持。
如果您使用注释了一个类@Data，它将基于字段名称为您生成getter和setter。如果您在另一个类中使用这些吸气剂之一，则确定该字段的命名不正确，它将找不到这些吸气剂和设置器的用法，并将旧名称替换为新名称。
我想这将必须通过IDE插件而不是Lombok来完成。
更新（13年1月22日）
使用Lombok 3个月后，我仍然建议大多数项目使用它。但是，我确实发现了另一个与上面列出的缺点类似的缺点。
如果你有一类，说MyCompoundObject.java的是有2名成员，都标注有@Delegate，说myWidgets和myGadgets，当你调用myCompoundObject.getThingies()从另一个类，这是不可能知道它是否委托给Widget或者Gadget因为你不能再跳到源在IDE中。
使用Eclipse的“生成委托方法...”可以为您提供相同的功能，并且同样快捷，并且可以进行源代码跳转。不利的一面是，它的样板代码使您的源代码混乱，从而使重点从重要的东西上移开。
更新2（2013年2月26日）
5个月后，我们仍在使用Lombok，但我还有其他烦恼。当您试图使自己熟悉新代码时，缺少声明的getter和setter会变得很烦人。
例如，如果我看到一个叫做的方法，getDynamicCols()但是我不知道它的含义，则我有一些额外的障碍可以跳过，以确定该方法的目的。有些障碍是Lombok，有些则缺少Lombok智能插件。障碍包括：
- 缺少JavaDocs。如果我使用javadoc字段，则希望getter和setter可以通过Lombok编译步骤继承该javadoc。
- 跳转到方法定义会将我跳转到该类，但不会跳转到生成该getter的属性。这是一个插件问题。
- 显然，除非生成或编写方法，否则您无法在getter / setter中设置断点。
- 注意：此参考搜索不是我最初认为的问题。您确实需要使用启用“大纲”视图的透视图。对于大多数开发人员而言，这不是问题。我的问题是我正在使用Mylyn过滤
Outline视图，因此我没有看到这些方法。 缺少参考文献搜索。如果要查看谁在打电话getDynamicCols(args...)，我必须生成或编写setter以便能够搜索参考。
更新3（13年7月7日）
我猜想学习在Eclipse中使用各种处理方式。您实际上可以在Lombok生成的方法上设置条件断点（BP）。使用Outline视图，可以右键单击该方法以Toggle Method Breakpoint。然后，当您单击BP时，可以使用调试Variables视图查看所生成的方法将其命名为什么参数（通常与字段名称相同），最后，使用该Breakpoints视图右键单击BP并选择Breakpoint Properties...添加条件。真好
更新4（13年8月16日）
当您在Maven pom中更新Lombok依赖项时，Netbeans不喜欢它。该项目仍然可以编译，但是文件被标记为存在编译错误，因为它看不到Lombok正在创建的方法。清除Netbeans缓存可以解决此问题。不确定是否像Eclipse中一样有“清理项目”选项。次要问题，但希望将其公开。
更新5（2014年1月17日）
Lombok并不总是与Groovy配合使用，或者至少与groovy-eclipse-compiler。您可能必须降级编译器的版本。
Maven Groovy和Java +龙目岛
更新6（14年6月26日）
警告。龙目岛（Lombok）会让人上瘾，如果您从事的项目由于某种原因而无法使用，那会惹恼您。根本不使用它可能会更好。
更新7（14年7月23日）
这是一个有趣的更新，因为它直接解决了安全问题了OP要求的采用Lombok。
从v1.14开始，@Delegate注释已降级为“实验”状态。详细信息记录在其站点上（Lombok Delegate Docs）。
问题是，如果您正在使用此功能，则您的退出选项受到限制。我将选项视为：
- 手动删除
@Delegate注释并生成/编码委托代码。如果您在注解中使用属性，则要困难一些。
- Delombok包含
@Delegate注释并可能添加回您想要的注释中。
- 切勿更新Lombok或维护叉子（或使用体验功能）。
- Delombok您的整个项目，然后停止使用Lombok。
据我所知，Delombok没有选择删除注释子集的选项；至少对于单个文件而言，它是全部还是什么都不是。我打开了一张票以请求此功能带有Delombok标志的，但我不希望在不久的将来有。
更新8（2014年10月20日）
如果您可以选择使用Groovy，则它具有Lombok的大部分相同优点，并且还提供了包括@Delegate在内的其他功能。如果您认为很难将创意推销到现有的功能上，请查看@CompileStatic或@TypeChecked注释，看看这是否对您的事业有所帮助。实际上，Groovy 2.0版本的主要焦点是静态安全性。。
更新9（15年9月1日）
龙目岛仍在积极维护和增强，这预示着采用的安全性水平。该@Builder注解是我最喜欢的新功能之一。
更新10（15年11月17日）
这似乎与OP的问题没有直接关系，但是值得分享。如果您正在寻找可帮助您减少编写的样板代码数量的工具，则还可以查看Google Auto-特别是AutoValue。如果您查看他们的幻灯片，则列表Lombok可能是他们尝试解决的问题的一种可能的解决方案。他们为龙目岛列出的缺点是：
- 插入的代码是不可见的（您无法“看到”它生成的方法）[编辑说明-确实可以，但是仅需要反编译器]
- 编译器黑客是非标准且脆弱的
- “在我们看来，您的代码不再是真正的Java”
我不确定我对他们的评价有多同意。考虑到幻灯片中记录的AutoValue的缺点，我会坚持使用Lombok（如果没有Groovy的话）。
更新11（2016年2月8日）
我发现Spring Roo具有一些类似的注释。当我发现Roo仍然是一件事情时，我感到有些惊讶，并且找到注释的文档有些粗糙。移除也不像去龙目岛那样容易。龙目岛似乎是更安全的选择。
更新12（16年2月17日）
在试图提出为什么可以安全地将Lombok用于我当前正在从事的项目的论据时，我发现v1.14在配置系统中添加了一块金牌！这意味着您可以配置项目以禁止团队认为不安全或不受欢迎的某些功能。更好的是，它还可以使用不同的设置创建目录特定的配置。这太棒了。
更新13（2016年10月4日）
如果这种事情对您很重要，Oliver Gierke认为将Lombok添加到Spring Data Rest中是安全的。
更新14（17年9月26日）
正如@gavenkoa在对OPs问题的评论中指出的那样，JDK9编译器支持尚不可用（问题＃985）。对于Lombok团队来说，听起来也不是一件容易的事。
更新15（18年3月26日）
Lombok更改日志指示从v1.16.20起“即使在＃985仍然打开的情况下，现在也可以在JDK1.9上编译 lombok” 。
但是，为了适应JDK9而进行的更改需要进行一些重大更改。全部隔离到配置默认值的更改。他们引入了重大更改，这有点令人担忧，但是该版本仅增加了“增量”版本号（从v1.16.18到v1.16.20）。由于这篇文章是关于安全性的，因此，如果您有一个yarn/npm类似的构建系统，该系统会自动升级到最新的增量版本，则可能会引起粗鲁的觉醒。
更新16（19年9月9日）
据我所知，似乎JDK9问题已解决，Lombok可与JDK10甚至JDK11一起使用。
从安全性方面来看，我注意到的一件事情是，从v1.18.2到v1.18.4的更改日志列出了两个项目BREAKING CHANGE！我不确定在semver“补丁”更新中如何发生重大变化。如果使用自动更新补丁程序版本的工具，可能会出现问题。
javac以打开对内部sun.*类的访问权限（（