使用龙目岛计划安全吗？[已关闭]

TL;博士：

是的，它使用起来非常安全，我建议使用它。（2022年5月）

原始答案

今天刚开始使用龙目岛。到目前为止，我喜欢它，但是我没有看到提到的一个缺点是重构支持。

如果您有一个标有 的类，它将根据字段名称为您生成 getter 和 setter。如果您在另一个类中使用其中一个 getter，则确定该字段命名不当，它将找不到这些 getter 和 setter 的用法，并将旧名称替换为新名称。@Data

我想这必须通过IDE插件而不是通过龙目岛来完成。

更新（2013年1月22日）
在使用龙目岛3个月后，我仍然推荐它用于大多数项目。但是，我确实发现了另一个与上面列出的缺点类似的缺点。

如果你有一个类，假设它有 2 个成员，这两个成员都用 、 say 和 注释，当你从另一个类调用时，不可能知道它是否委托给 或者因为你不能再跳转到 IDE 中的源代码。MyCompoundObject.java@DelegatemyWidgetsmyGadgetsmyCompoundObject.getThingies()WidgetGadget

使用 Eclipse “Generate Delegate Methods...”为您提供相同的功能，同样快速并提供源跳转。缺点是它使您的源代码混乱，样板代码将注意力从重要内容上移开。

更新2（2013年2月26日）
5个月后，我们仍在使用龙目岛，但我还有其他一些烦恼。缺少声明的 getter & setter 有时会让您在尝试熟悉新代码时感到烦恼。

例如，如果我看到一个调用的方法，但我不知道它是什么，我有一些额外的障碍要跳过来确定此方法的目的。有些障碍是龙目岛，有些是缺乏龙目岛智能插件。障碍包括：getDynamicCols()

• 缺乏JavaDocs。如果我使用javadoc字段，我希望getter和setter能够通过龙目岛编译步骤继承javadoc。
• 跳转到方法定义会将我跳转到类，但不会跳转到生成 getter 的属性。这是一个插件问题。
• 显然，除非您生成或编码该方法，否则您无法在 getter/setter 中设置断点。
• 注意：此参考搜索不是我最初认为的问题。不过，您确实需要使用启用大纲视图的透视。对于大多数开发人员来说不是问题。我的问题是我正在使用Mylyn，它正在过滤我的视图，所以我没有看到这些方法。缺少参考文献搜索。如果我想看看谁在调用getDynamicCols（args...），我必须生成或编码设置器才能搜索引用。Outline

UPDATE 3 （Mar 7 '13）
我想学习在Eclipse中使用各种做事方式。您实际上可以在龙目岛生成的方法上设置条件断点（BP）。使用该视图，可以右键单击该方法以。然后，当您点击 BP 时，可以使用调试视图查看生成的方法对参数的命名（通常与字段名称相同），最后，使用该视图右键单击 BP 并选择添加条件。好。OutlineToggle Method BreakpointVariablesBreakpointsBreakpoint Properties...

UPDATE 4 （Aug 16 '13）
Netbeans 不喜欢您在 Maven pom 中更新龙目岛依赖项。该项目仍在编译，但文件被标记为存在编译错误，因为它看不到龙目岛正在创建的方法。清除 Netbeans 缓存可解决此问题。不确定是否有像Eclipse中那样的“清理项目”选项。小问题，但想让大家知道。

更新5（2014年1月17日）
龙目岛并不总是与Groovy一起玩得很好，或者至少是.您可能需要降级编译器版本。Maven Groovy 和 Java + Lombokgroovy-eclipse-compiler

更新6（2014年6月26日）
警告一句话。龙目岛有点上瘾，如果你从事一个项目，由于某种原因你不能使用它，它会惹恼你的尿液。你可能最好只是根本不使用它。

更新7（2014年7月23日）
这是一个有趣的更新，因为它直接解决了OP询问的采用龙目岛的安全性。

从 v1.14 开始，注释已降级为实验状态。详细信息记录在他们的网站上（龙目岛代表文档）。@Delegate

问题是，如果您使用的是此功能，则回退选项是有限的。我认为选项是：

• 手动删除批注并生成/手动编码委托代码。如果您在批注中使用属性，则这有点困难。@Delegate
• Delombok 具有批注的文件，并可能添加回您想要的批注。@Delegate
• 永远不要更新龙目岛或维护分叉（或使用体验功能）。
• Delombok您的整个项目并停止使用龙目岛。

据我所知，Delombok没有删除注释子集的选项;至少对于单个文件的上下文来说，它是全部或全部没有。我打开了一张票，用Delombok标志请求此功能，但我不希望在不久的将来这样做。

UPDATE 8 （Oct 20 '14）
如果这是您的选择，Groovy提供了龙目岛的大部分相同优势，以及包括@Delegate在内的其他功能。如果你认为你很难将这个想法卖给当权者，看看或注释，看看这是否可以帮助你的事业。事实上，Groovy 2.0版本的主要重点是静态安全。@CompileStatic@TypeChecked

更新9（2015年9月1日）
龙目岛仍在积极维护和增强，这对采用的安全性水平来说是个好兆头。@Builder注释是我最喜欢的新功能之一。

更新10（15年11月17日）
这似乎与OP的问题没有直接关系，但值得分享。如果您正在寻找工具来帮助您减少编写的样板代码量，您还可以查看Google Auto - 特别是AutoValue。如果你看看他们的幻灯片，将龙目岛列为他们试图解决的问题的可能解决方案。他们为龙目岛列出的缺点是：

• 插入的代码是不可见的（你不能“看到”它生成的方法）[ed注意 - 实际上你可以，但它只需要一个反编译器]
• 编译器黑客是非标准和脆弱的
• “在我们看来，你的代码不再是真正的Java”

我不确定我有多同意他们的评价。鉴于幻灯片中记录的AutoValue的缺点，我将坚持使用龙目岛（如果Groovy不是一个选项）。

更新11（2016年2月8日）
我发现Spring Roo有一些类似的注释。我有点惊讶地发现Roo仍然是一件事情，找到注释的文档有点粗糙。移除看起来也不像去龙目岛那么容易。龙目岛似乎是更安全的选择。

更新12（2016年2月17日）
在试图提出为什么为我目前正在从事的项目引入龙目岛是安全的理由时，我发现了一块黄金 - 配置系统！这意味着您可以将项目配置为不允许您的团队认为不安全或不受欢迎的某些功能。更好的是，它还可以使用不同的设置创建特定于目录的配置。这真是太棒了。v1.14

更新13（2016年10月4日）
如果这种事情对你来说很重要，Oliver Gierke认为将龙目岛添加到Spring Data Rest是安全的。

UPDATE 14 （Sep 26 '17）
正如@gavenkoa在关于OP问题的评论中指出的那样，JDK9编译器支持尚不可用（问题#985）。这听起来也不像龙目岛团队那样容易解决。

更新15（2018年3月26日）
龙目岛更改日志显示，自v1.16.20起，“现在可以在JDK1.9上编译龙目岛”，即使#985仍然开放。

然而，为了适应JDK9而进行的更改需要一些重大更改。全部与配置默认值中的更改隔离。他们引入了重大更改，这有点令人担忧，但该版本只碰到了“增量”版本号（从v1.16.18到v1.16.20）。由于这篇文章是关于安全性的，如果你有一个类似的构建系统，自动升级到最新的增量版本，你可能会粗鲁地醒来。yarn/npm

更新 16 （2019 年 1 月 9 日）

据我所知，JDK9问题似乎已经得到解决，龙目岛可以与JDK10甚至JDK11一起使用。

从安全角度来看，我注意到的一件事是，从v1.18.2到v1.18.4的更改日志将两个项目列为！？我不确定在semver“补丁”更新中如何发生重大更改。如果您使用自动更新修补程序版本的工具，则可能会出现问题。BREAKING CHANGE

更新 17 （2021 年 3 月 17 日）

龙目岛开发者和 OpenJDK 开发者围绕 JDK 16 展开了一些戏剧性事件。JDK开发人员认为，龙目岛正在通过JDK团队想要关闭的漏洞来利用未发布的JDK内部，但由于各种原因故意保持开放。

他们表达了他们的担忧（关于龙目岛的安全）是这样的：

对内部的所有访问都将像以前一样保持可用，前提是客户端应用程序明确允许它，并承认它正在故意承担这可能带来的任何维护（或安全性）问题。

虽然龙目岛可能认为他们在欺骗OpenJDK，但他们所做的只是宣布他们打算欺骗自己的用户。

可能很快就会有一天，龙目岛将无法围绕JDK的安全限制找到任何创造性的解决方案。即使他们这样做，在您的项目中使用龙目岛的安全性也可能受到质疑。

更新 18 （222 年 5 月 11 日）

最近的一条评论要求提供摘要，所以我把它放在了顶部。

简短的答案是，如果我们要编写Java代码，我强烈建议使用它。

鉴于对JDK 17的支持已经退出了一段时间，并且在JDK正式发布后不到一个月就发布了，龙目岛坚持下去的安全性很高。如果需要，您可以随时取消龙目岛。

作为一名顾问，我可以看到很多不同的公司是如何编写代码的。在过去的5年里，我遇到的每个客户都使用过龙目岛。这些都是财富1000强公司。它加快了开发速度，使其不易出错。

也就是说，您仍然需要跟上JDK的最新功能。考虑使用 Java 关键字来使您的对象不可变，而不是某些龙目岛功能。在有意义的地方使用龙目岛。使用龙目岛配置选项来防止以您不同意的方式使用它。record

因此，除非发生重大事件，否则这可能是我对此答案的最后一次更新。感谢所有的投票。我很高兴它有帮助。

听起来您已经决定龙目岛项目为您提议的新项目提供显着的技术优势。（从一开始就要清楚的是，我对龙目岛项目没有特别的看法，不管怎样。

在某个项目（开源或其他明智的项目）中使用龙目岛项目（或任何其他改变游戏规则的技术）之前，您需要确保项目利益相关者同意这一点。这包括开发人员和任何重要用户（例如正式或非正式赞助商）。

您提到了这些潜在问题：

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

容易。忽略/不要参与火焰战，或者只是不要提到龙目岛。

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

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

人们会抱怨缺少JavaDoc，

这是他们的问题。没有一个头脑正常的人试图将他们组织的源代码/文档规则严格地应用于第三方开源软件。项目团队应该可以自由地设置适合所用技术的项目源代码/文档标准。

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

未来的提交者可能会无论如何都会全部删除它。

那不开！如果商定的项目策略是使用龙目岛，那么无偿取消龙目岛代码的提交者应该受到惩罚，并在必要时撤销他们的提交权。

当然，这假设您已经得到了利益相关者的支持......包括开发人员。它假设你准备为你的事业辩护，并适当地处理不可避免的不同意见。