使用龙目计划安全吗?[关闭]

在将projectlombok(或任何其他改变游戏规则的技术)用于某个项目(开源或其他方式)之前,您需要确保项目的利益相关者同意这一点。这包括开发者和任何重要的用户(例如正式或非正式的赞助商)。

当我提到它时,###Java Freenode频道会爆发火爆战争,

容易的。忽略/不要参加火爆战争,或者干脆不提龙目山。

如果项目策略是使用Lombok,那么可能的帮助者需要习惯它。

人们会抱怨失踪的JavaDoc,

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

而未来的犯罪者可能会把它全部删除。

那不是开的!如果约定的项目策略是使用Lombok,那么无偿取消Lombok代码的提交者应该受到惩罚,如果必要的话,他们的提交权应该被撤销。

当然,这是假设你已经得到了利益相关者的认同。。。包括开发商。它假设你准备好为自己的事业辩护,并适当地处理不可避免的不同意见。

今天刚开始使用龙目山。到目前为止,我很喜欢它,但是有一个缺点我没有提到,那就是重构支持。

如果你有一个用 @Data ,它将根据字段名为您生成getter和setter。如果您在另一个类中使用其中一个getter,然后确定字段的名称不正确,那么它将找不到这些getter和setter的用法,并用新名称替换旧名称。

我可以想象这必须通过IDE插件来完成,而不是通过Lombok。

更新(2013年1月22日)
在使用Lombok 3个月之后,我仍然推荐它用于大多数项目。不过,我确实发现了另一个类似于上面列出的缺点。

MyCompoundObject.java @Delegate ,说 myWidgets 和 myGadgets myCompoundObject.getThingies() 从另一个类,不可能知道它是否授权给 Widget 或 Gadget 因为您不能再跳转到IDE中的源代码。

更新2(2013年2月26日)

例如,如果我看到一个名为 getDynamicCols() 但我不知道这是关于什么的,我有一些额外的障碍来决定这个方法的目的。有些障碍是Lombok,有些是Lombok智能插件的缺乏。障碍包括:

• 跳转到方法定义会跳转到类,但不会跳转到生成getter的属性。这是一个插件问题。
• 显然,除非生成或编写方法,否则无法在getter/setter中设置断点。
• Outline 视图,所以我没有看到方法。 缺少参考文献搜索。如果我想知道是谁打来的 getDynamicCols(args...)

更新3(2013年3月7日)
我想学习使用Eclipse中的各种方法。实际上,您可以在Lombok生成的方法上设置条件断点(BP)。使用 轮廓 Toggle Method Breakpoint . 然后当你点击BP时,你就可以使用调试了 Variables 查看生成的方法将哪些参数命名(通常与字段名相同),最后,使用 Breakpoints 视图右键单击BP并选择 Breakpoint Properties... 添加条件。不错。

Netbeans不喜欢在Maven pom中更新Lombok依赖项。项目仍在编译,但文件会被标记为有编译错误,因为它看不到Lombok正在创建的方法。清除Netbeans缓存可以解决这个问题。不确定是否有像Eclipse中那样的“cleanproject”选项。小问题,但想让大家知道。

更新5(2014年1月17日)
groovy-eclipse-compiler . 您可能必须降级编译器的版本。 Maven Groovy and Java + Lombok

更新6(2014年6月26日)
一句警告。龙目山是有点上瘾,如果你在一个项目,你不能使用它的某些原因,它会惹恼你的尿。你最好不要用它。

这是一个有趣的更新,因为它直接解决了 关于采用龙目山的问题。

从v1.14开始 批注已降级为实验状态。细节记录在他们的网站上( Lombok Delegate Docs ).

问题是,如果您使用此功能,您的回退选项是有限的。我认为选项如下:

• 手动删除 注释并生成/手工编码委托代码。如果您在注释中使用属性,这会有点困难。
• 删除包含 @代表 注释,并可能添加回您想要的注释。
• 删除整个项目,停止使用Lombok。

Delombok doesn't have an option to remove a subset of annotations ;至少在单个文件的上下文中是全部或全部。我打开了 a ticket to request this feature 带着德隆伯克旗,但我不希望在不久的将来。

更新8(2014年10月20日)
@Delegate @CompileStatic 或 @TypeChecked 看看这对你的事业是否有帮助。事实上, the primary focus of the Groovy 2.0 release was static safety .

更新9(2015年9月1日)
actively maintained and enhanced ,这预示着收养的安全水平。这个 @Builder

更新10(2015年11月17日)
这似乎与OP的问题没有直接关系,但值得分享。如果您正在寻找一些工具来帮助您减少所编写的样板代码的数量,您还可以查看 Google Auto AutoValue slide deck ,列出龙目山作为他们试图解决的问题的可能解决方案。他们列出的龙目岛的缺点是:

• 插入的代码是不可见的(你不能“看到”它生成的方法)[注-实际上你可以,但它只需要一个反编译器]

我不确定我有多同意他们的评价。考虑到幻灯片中记录的AutoValue的缺点,我将继续使用Lombok(如果Groovy不是一个选项的话)。

我发现了 Spring Roo similar annotations . 我有点惊讶地发现Roo仍然是一个东西,并且为注释找到文档有点粗糙。移除也不像de lombok那么容易。龙目山似乎是比较安全的选择。

更新12(2016年2月17日)
当我试图为我目前从事的项目引入龙目山是安全的提出理由时,我发现了一块添加了 v1.14 -那个 Configuration System ! 这意味着您可以将项目配置为不允许团队认为不安全或不需要的某些功能。更好的是,它还可以使用不同的设置创建特定于目录的配置。这太棒了。

如果这种事对你很重要, Oliver Gierke add Lombok to Spring Data Rest .

更新14(2017年9月26日)
正如 @gavenkoa JDK9 compiler support isn't yet available (第985期)。这听起来似乎也不是一个简单的解决办法,龙目山队要绕过。

更新15(2018年3月26日)
Lombok变更日志显示从v1.16.20开始” Compiling lombok on JDK1.9 is now possible #985 仍然开放。

然而,为了适应JDK9而进行的更改需要一些突破性的更改;所有更改都与配置默认值中的更改隔离开来。有点担心的是,他们引入了突破性的更改,但版本只是增加了“增量”版本号(从v1.16.18到v1.16.20)。既然这篇文章是关于安全的,如果你有 yarn/npm

更新16(2019年1月9日)

看来 the JDK9 issues have been resolved Lombok可以使用JDK10,据我所知,甚至可以使用JDK11。

BREAKING CHANGE

更新16(3月17日至21日)

The JDK developers argue Lombok通过JDK团队希望关闭的漏洞利用了未发布的JDK内部构件,但由于各种原因故意留下了漏洞。

They have stated their concern (关于龙目岛的安全)因此:

故意承担任何维护(或安全)问题 包含。

虽然Lombok可能认为他们在欺骗OpenJDK,但他们所做的一切 宣布这是他们的意图欺骗自己的用户。

继续使用Lombok,如果必要的话,您可以在以后“delombok”您的代码 http://projectlombok.org/features/delombok.html

使用时

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

与任何IDE/own实现相比,保持Equals&HashCode的一致性并跟踪要计算的字段要容易得多。当您仍在定期添加/删除字段时尤其如此。

这同样适用于 @ToString 注释及其参数,它们清楚地传达了所需的行为,包括/排除字段、getter的使用或字段访问以及是否调用 super.toString() .

再次用 @Getter 或 @Setter(AccessLevel.NONE) (并且可以选择性地重写任何不同的方法)很快就会清楚哪些方法可以用于这些字段。

好处不断。。

在我看来,这不是减少代码,而是清楚地传达您想要实现的目标,而不是必须从Javadoc或实现中找出答案。减少的代码只会使发现任何不同的方法实现变得更容易。

我读了一些关于龙目山的观点,实际上我正在一些项目中使用它。

嗯,在第一次接触龙目山时,我的印象不好。几周后,我开始喜欢它了。但几个月后,我用它解决了很多小问题。所以,我对龙目山的最后印象不是很好。

我这样想的理由:

• IDE插件依赖项 . Lombok的IDE支持是通过插件实现的。即使在大部分时间里工作得很好,您也总是这个插件的人质,这些插件将在IDE和Linux的未来版本中维护 even the language version
• “查找用法”问题。
• 如此简单以至于开发人员不想破坏封装 . 我知道这不是龙目山的问题。但我看到开发人员有一个更大的趋势,即不再控制哪些方法需要可见或不可见。所以,很多时候,他们只是复制和粘贴 @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor 注释阻塞而不考虑类真正需要公开的方法。
• 生成器obsession . 我发明了这个名字(下车,马丁福勒)。除此之外,构建器非常容易创建,即使一个类只有两个参数,开发人员也更喜欢使用 @Builder MyClass.builder().name("Name").build().create() .
• 重构时的障碍 . 例如,如果您使用 @AllArgsConstructor 并且需要在构造函数上再添加一个参数,IDE不能帮助您在实例化类的所有地方(主要是测试)添加这个额外的参数。
• 龙目山混凝土搅拌法

就像另一个答案所说的那样,如果你对Java的冗长感到愤怒并使用Lombok来处理它,那么试试Kotlin。

龙目山很棒,但是。。。

注释处理以一系列循环运行。在每一轮中,每个人都有一个回合可以跑。如果在回合结束后发现任何新的java文件,则另一回合开始。这样,如果注释处理器只生成新文件,它们的顺序就无关紧要了。由于lombok不生成任何新文件,因此没有新的回合开始,因此一些依赖lombok代码的AP无法按预期运行。在使用mapstruct时,这对我来说是一个巨大的痛苦来源,而delombok ing不是一个有用的选项,因为它会破坏日志中的行号。

我最终入侵了一个构建脚本,使其同时与lombok和mapstruct一起工作。但我想放弃龙目山,因为它有多黑——至少在这个项目中。我在其他事情上总是用龙目山。

也存在长期维护风险。首先,我建议阅读Lombok的实际工作原理,例如,它的开发人员给出的一些答案 here .

官方网站还包含 list of downsides

运行在javac中的注释处理器将获得 JavacAnnotationProcessor,它是 在直播时使用的额外方法)。

在eclipse上,可以说是更糟糕(而且更健壮)的java代理 当然,这是完全非公开的API,完全禁止使用。

如果你能像lombok那样使用标准API,我早就做到了 在Java1.5上运行的EclipseV3.4上进行任何更改

总之,虽然Lombok可能会为您节省一些开发时间,但如果存在不向后兼容的javac更新(例如漏洞缓解),Lombok可能会让您在开发人员争相更新其内部api使用情况的同时被旧版本的Java困住。这是否是一个严重的风险显然取决于项目。

我知道我迟到了,但我无法抗拒诱惑:任何喜欢龙目山的人也应该看看斯卡拉。你在龙目岛发现的许多好主意都是Scala语言的一部分。

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

作为免责声明:我也喜欢Java!

一年来,我几乎在所有的项目中都使用了Lombok,但不幸的是,我删除了它。一开始,这是一种非常干净的开发方式,但是为新的团队成员建立开发环境并不是非常简单和直接的。当它变成头痛时,我就把它去掉了。但这是一个很好的工作,需要一些更简单的设置。

• 就ROI而言,它是一个快速集成的过程,并且不需要对其基本形式进行任何代码更改。(只是在类中添加一个注释)

• 最后,如果您改变主意,您可以运行unmbok,或者让您的IDE创建这些setter、getter和actor(我认为,一旦看到您的pojo变得多么清晰,就没有人会要求这样做了)

我对Lombok的看法是,它只提供了编写bolilerplate Java代码的快捷方式。

1. 它用替代语法(read)的间接层污染了代码 @Getter @Setter 等注释)。我不想学习Java的另一种语法,而是转而使用任何其他本机提供类似Lombok语法的语言。
2. Lombok需要使用Lombok支持的IDE来处理代码。这种依赖性为任何非平凡的项目带来了相当大的风险。开源Lombok项目是否有足够的资源来支持各种javaide的不同版本?
4. 我还感到紧张的是,Lombok可能会引入与广泛使用的框架/库(如Spring、Hibernate、Jackson、JUnit、Mockito)的兼容性问题,这些框架/库在运行时处理字节码。

想用龙目山的 @ToString 但很快在Intellij IDEA的项目重建中就遇到了随机编译错误。在增量编译成功完成之前,必须多次点击compile。

在JDK1.6.0Ə39和1.6.0Ə45下使用Intellij IDEA 12.1.6和13.0尝试了lombok 1.12.2和0.9.3,但没有任何lombok插件。

只有启用并行编译时才会出现问题。

https://github.com/rzwitserloot/lombok/issues/648

更新

mplushnikov于2016年1月30日发表评论:

再也没有这样的问题了。我想这里可以关门。

更新

Kotlin 如果可能的话。 因为它从一开始就解决了Lombok试图解决的所有Java问题。

和 杰克逊CSV ,当我将我的对象(javabean)封送到一个CSV文件时,列被复制了,然后我删除了Lombok的@Data注释,封送处理工作正常。

我不推荐。我曾经用过它,但是当我使用netbeans7.4时,它把我的代码弄乱了。我必须在我的项目中删除所有文件中的lombok。有德隆伯克,但我怎么能确定它不会破坏我的代码。我不得不花上几天的时间来移除lombok并恢复到普通的Java风格。我只是太辣了。。。

https://code.google.com/p/projectlombok/issues/detail?id=451 .