Java 使用 Project Lombok 安全吗？

Is it safe to use Project Lombok?

提问by TheLQ

In case you don't know Project Lombokhelps with some of the annoyances of Java with stuff like generating getters and setters with annotationsand even simple JavaBean like generation with @Data. It could really help me, especially in 50 different event objects where you have up to 7 different fields that need to be constructed and hidden with getters. I could remove almost a thousand lines of code with this.

如果您不知道Project Lombok可以帮助解决 Java 的一些烦恼，例如使用注释生成 getter 和 setter，甚至像使用 @Data 生成简单的 JavaBean。它真的可以帮到我，尤其是在 50 个不同的事件对象中，你有多达 7 个不同的字段需要用 getter 构造和隐藏。我可以用这个删除近一千行代码。

However, I'm worried that in the long run, it will be a regretful decision. Flamewars will erupt in the ##Java Freenodechannel when I mention it, providing code snippets will confuse possible helpers, people will complain about missing JavaDoc, and future commiters might just remove it all anyway. I would really enjoy the positive, but I'm worried about the negative.

但是，我担心从长远来看，这将是一个令人遗憾的决定。##Java Freenode当我提到它时，Flamewars 会在频道中爆发，提供代码片段会混淆可能的帮助者，人们会抱怨缺少 JavaDoc，而未来的提交者可能会无论如何都将其删除。我真的很喜欢积极的一面，但我担心消极的一面。

So: Is it safe to use Lombok on any project, small or large? Are the positive effects worth the negatives?

那么：在任何项目中使用 Lombok 安全吗，无论大小？积极的影响值得消极的影响吗？

采纳答案by Stephen C

It sounds like you've already decided that Project Lombok gives you significant technical advantages for your proposed new project. (To be clear from the start, I have no particular views on Project Lombok, one way or the other.)

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

Before you use Project Lombok (or any other game-changing technology) in some project (open source or other wise), you need to make sure that the project stake holders agree to this. This includes the developers, and any important users (e.g. formal or informal sponsors).

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

You mention these potential issues:

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

Flamewars will erupt in the ##Java Freenode channel when I mention it,

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

Easy. Ignore / don't participate in the flamewars, or simply refrain from mentioning Lombok.

简单。忽略/不参与火焰War，或者干脆不要提及龙目岛。

providing code snippets will confuse possible helpers,

提供代码片段会混淆可能的助手，

If the project strategy is to use Lombok, then the possible helpers will need to get used to it.

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

people will complain about missing JavaDoc,

人们会抱怨缺少 JavaDoc，

That is their problem. Nobody in their right mind tries to rigidly apply their organization's source code / documentation rules to third-party open source software. The project team should be free to set project source code / documentation standards that are appropriate to the technology being used.

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

(FOLLOWUP- The Lombok developers recognize that not generating javadoc comments for synthesized getter and setter methods is an issue. If this is a major problem for your project(s), then one alternative is to create and submit a Lombok patch to address this.)

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

and future commiters might just remove it all anyway.

无论如何，未来的提交者可能只是将其全部删除。

That's not on! If the agreed project strategy is to use Lombok, then commiters who gratuitously de-Lombok the code should be chastised, and if necessary have their commit rights withdrawn.

那没开！如果商定的项目策略是使用 Lombok，那么无缘无故地去 Lombok 代码的提交者应该受到惩罚，并在必要时撤销他们的提交权。

Of course, this assumes that you've got buy-in from the stakeholders ... including the developers. And it assumes that you are prepared to argue your cause, and appropriately handle the inevitable dissenting voices.

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

回答by Kennet

Go ahead and use Lombok, you can if necessary "delombok" your code afterwards http://projectlombok.org/features/delombok.html

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

回答by Tim

Personally (and therefore subjectively) I've found that using Lombok makes my code more expressive about what I'm trying to achieve when compared to IDE/own implementations of intricate methods such as hashcode & equals.

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

When using

使用时

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

it's much easier to keep Equals & HashCode consistent and keep track of which fields are evaluated, than any IDE/own implementation. This is especially true when you're still adding / removing fields regularly.

与任何 IDE/自己的实现相比，保持 Equals & HashCode 一致并跟踪评估哪些字段要容易得多。当您仍在定期添加/删除字段时尤其如此。

The same goes for the @ToStringannotation and its parameters which clearly communicate the desired behavior regarding included / excluded fields, usage of getters or field access and wether or not to call super.toString().

这同样适用于所述@ToString注释和它的参数，其清楚地传达关于包括/排除字段，吸气剂或字段访问的和阉羊使用或不呼叫所需的行为super.toString()。

And again by annotating an entire class with @Getteror @Setter(AccessLevel.NONE)(and optionally overriding any divergent methods) it's immediately clear what methods will be available for the fields.

再次通过使用@Getteror注释整个类@Setter(AccessLevel.NONE)（并可选地覆盖任何不同的方法），可以立即清楚哪些方法可用于字段。

The benefits go on and on..

好处还在继续。。

In my mind it's not about reducing code, but about clearly communicating what you desire to achieve, rather than having to figure it out from Javadoc or implementations. The reduced code just makes it easier to spot any divergent-method implementations.

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

回答by Dov Tsal S

When I showed the project to my team the enthusiasm was high, so I think you should not be afraid of team response.

当我向我的团队展示这个项目时，他们的热情很高，所以我认为你不应该害怕团队的反应。

• As far as ROI, it is a snap to integrate, and requires no code change in its basic form. (just adding a single annotation to your class)

• And last, if you change your mind, you can run the unlombok, or let your IDE create these setters, getters, and ctors, (which I think no one will ask for once they see how clear your pojo becomes)

• 就 ROI 而言，它很容易集成，并且不需要更改其基本形式的代码。（只需向您的班级添加一个注释）

• 最后，如果你改变主意，你可以运行 unlombok，或者让你的 IDE 创建这些 setter、getter 和 ctors，（我认为一旦他们看到你的 pojo 变得多么清晰，没有人会要求）

回答by vici

I have used Lombok in almost all my projects for one year but unfortunately removed it. In the beginning it was a very clean way of development but setting up the development environment for new team members is not very easy and straightforward. When it became a headache I just removed it. But it is a good work and needs some more simplicity to setting up.

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

回答by Snekse

Just started using Lombok today. So far I like it, but one drawback I didn't see mentioned was refactoring support.

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

If you have a class annotated with @Data, it will generate the getters and setters for you based on the field names. If you use one of those getters in another class, then decide the field is poorly named, it will not find usages of those getters and setters and replace the old name with the new name.

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

I would imagine this would have to be done via an IDE plug-in and not via Lombok.

我想这必须通过 IDE 插件来完成，而不是通过 Lombok。

UPDATE (Jan 22 '13)
After using Lombok for 3 months, I still recommend it for most projects. I did, however, find another drawback that is similar to the one listed above.

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

If you have a class, say MyCompoundObject.javathat has 2 members, both annotated with @Delegate, say myWidgetsand myGadgets, when you call myCompoundObject.getThingies()from another class, it's impossible to know if it's delegating to the Widgetor Gadgetbecause you can no longer jump to source within the IDE.

如果你有一个类，假设MyCompoundObject.java它有 2 个成员，都用@Delegate, saymyWidgets和注释myGadgets，当你myCompoundObject.getThingies()从另一个类调用时，不可能知道它是委托给Widget还是Gadget因为你不能再跳转到 IDE 中的源代码。

Using the Eclipse "Generate Delegate Methods..." provides you with the same functionality, is just as quick and provides source jumping. The downside is it clutters your source with boilerplate code that take the focus off the important stuff.

使用 Eclipse“生成委托方法...”为您提供相同的功能，同样快速并提供源代码跳转。缺点是它会用样板代码使您的源代码变得混乱，从而将重点从重要的东西上移开。

UPDATE 2 (Feb 26 '13)
After 5 months, we're still using Lombok, but I have some other annoyances. The lack of a declared getter & setter can get annoying at times when you are trying to familiarize yourself with new code.

更新 2（2013 年 2 月 26 日）
5 个月后，我们仍在使用 Lombok，但我还有其他一些烦恼。当您试图熟悉新代码时，缺少声明的 getter 和 setter 有时会很烦人。

For example, if I see a method called getDynamicCols()but I don't know what it's about, I have some extra hurdles to jump to determine the purpose of this method. Some of the hurdles are Lombok, some are the lack of a Lombok smart plugin. Hurdles include:

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

• Lack of JavaDocs. If I javadoc the field, I would hope the getter and setter would inherit that javadoc through the Lombok compilation step.
• Jump to method definition jumps me to the class, but not the property that generated the getter. This is a plugin issue.
• Obviously you are not able to set a breakpoint in a getter/setter unless you generate or code the method.
• NOTE: This Reference Search is not an issue as I first thought it was. You do need to be using a perspective that enables the Outline view though. Not a problem for most developers. My problem was I am using Mylyn which was filtering my Outlineview, so I didn't see the methods. Lack of References search. If I want to see who's calling getDynamicCols(args...), I have to generate or code the setter to be able to search for references.

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

UPDATE 3 (Mar 7 '13)
Learning to use the various ways of doing things in Eclipse I guess. You can actually set a conditional breakpoint (BP) on a Lombok generated method. Using the Outlineview, you can right-click the method to Toggle Method Breakpoint. Then when you hit the BP, you can use the debugging Variablesview to see what the generated method named the parameters (usually the same as the field name) and finally, use the Breakpointsview to right-click the BP and select Breakpoint Properties...to add a condition. Nice.

更新 3（2013 年 3 月 7 日）
我猜我想学习在 Eclipse 中使用各种做事方式。您实际上可以在 Lombok 生成的方法上设置条件断点 (BP)。使用该Outline视图，您可以右键单击该方法以Toggle Method Breakpoint。然后当你点击BP时，你可以使用调试Variables视图查看生成的方法命名参数（通常与字段名称相同），最后使用Breakpoints视图右键单击BP并选择Breakpoint Properties...添加条件。好的。

UPDATE 4 (Aug 16 '13)
Netbeans doesn't like it when you update your Lombok dependencies in your Maven pom. The project still compiles, but files get flagged for having compilation errors because it can't see the methods Lombok is creating. Clearing the Netbeans cache resolves the issue. Not sure if there is a "Clean Project" option like there is in Eclipse. Minor issue, but wanted to make it known.

更新 4（2013 年 8 月 16 日）
当您更新 Maven pom 中的 Lombok 依赖项时，Netbeans 不喜欢它。项目仍然可以编译，但文件被标记为存在编译错误，因为它看不到 Lombok 正在创建的方法。清除 Netbeans 缓存可解决此问题。不确定是否有像 Eclipse 中那样的“Clean Project”选项。小问题，但想让它知道。

UPDATE 5 (Jan 17 '14)
Lombok doesn't always play nice with Groovy, or at least the groovy-eclipse-compiler. You might have to downgrade your version of the compiler. Maven Groovy and Java + Lombok

更新 5（2014 年 1 月 17 日）
Lombok 并不总是与 Groovy 搭配得很好，或者至少与groovy-eclipse-compiler. 您可能需要降级编译器的版本。 Maven Groovy 和 Java + Lombok

UPDATE 6 (Jun 26 '14)
A word of warning. Lombok is slightly addictive and if you work on a project where you can't use it for some reason, it will annoy the piss out of you. You may be better off just never using it at all.

更新 6（2014 年 6 月 26 日）
警告。Lombok 有点让人上瘾，如果你从事的项目由于某种原因无法使用它，它会让你生气。根本不使用它可能会更好。

UPDATE 7 (Jul 23 '14)
This is a bit of an interesting update because it directly addresses the safetyof adopting Lombok that the OP asked about.

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

As of v1.14, the @Delegateannotation has been demoted to an Experimental status. The details are documented on their site (Lombok Delegate Docs).

从 v1.14 开始，@Delegate注释已降级为实验状态。详细信息记录在他们的网站 ( Lombok Delegate Docs) 上。

The thing is, if you were using this feature, your backout options are limited. I see the options as:

问题是，如果您使用此功能，您的退出选项将受到限制。我看到的选项是：

• Manually remove @Delegateannotations and generate/handcode the delegate code. This is a little harder if you were using attributes within the annotation.
• Delombok the files that have the @Delegateannotation and maybe add back in the annotations that you do want.
• Never update Lombok or maintain a fork (or live with using experiential features).
• Delombok your entire project and stop using Lombok.

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

As far as I can tell, Delombok doesn't have an option to remove a subset of annotations; it's all or nothing at least for the context of a single file. I opened a ticket to request this featurewith Delombok flags, but I wouldn't expect that in the near future.

据我所知，Delombok 没有删除注释子集的选项；至少对于单个文件的上下文而言，它要么全有要么全无。我打开了一张带有 Delombok 标志的请求此功能的票，但我不希望在不久的将来。

UPDATE 8 (Oct 20 '14)
If it's an option for you, Groovy offers most of the same benefits of Lombok, plus a boat load of other features, including @Delegate. If you think you'll have a hard time selling the idea to the powers that be, take a look at the @CompileStaticor @TypeCheckedannotation to see if that can help your cause. In fact, the primary focus of the Groovy 2.0 release was static safety.

更新 8（2014 年 10 月 20 日）
如果它是您的选择，Groovy 提供与 Lombok 相同的大部分优势，以及大量其他功能，包括@Delegate。如果你认为你很难将这个想法推销给权力，请查看@CompileStatic或@TypeChecked注释，看看这是否有助于你的事业。事实上，Groovy 2.0 版本的主要焦点是静态安全性。

UPDATE 9 (Sep 1 '15)
Lombok is still being actively maintained and enhanced, which bodes well to the safety level of adoption. The @Builderannotations is one of my favorite new features.

更新 9（2015 年 9 月 1 日）
Lombok 仍在积极维护和增强，这预示着采用的安全水平。该@Builder注解是我最喜欢的新功能之一。

UPDATE 10 (Nov 17 '15)
This may not seem directly related to the OP's question, but worth sharing. If you're looking for tools to help you reduce the amount of boilerplate code you write, you can also check out Google Auto- in particular AutoValue. If you look at their slide deck, the list Lombok as a possible solution to the problem they are trying to solve. The cons they list for Lombok are:

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

• The inserted code is invisible (you can't "see" the the methods it generates) [ed note - actually you can, but it just requires a decompiler]
• The compiler hacks are non-standard and fragile
• "In our view, your code is no longer really Java"

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

I'm not sure how much I agree with their evaluation. And given the cons of AutoValue that are documented in the slides, I'll be sticking with Lombok (if Groovy is not an option).

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

UPDATE 11 (Feb 8 '16)
I found out Spring Roohas some similar annotations. I was a little surprised to find out Roo is still a thing and finding documentation for the annotations is a bit rough. Removal also doesn't look as easy as de-lombok. Lombok seems like the safer choice.

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

UPDATE 12 (Feb 17 '16)
While trying to come up with justifications for why it's safe to bring in Lombok for the project I'm currently working on, I found a piece of gold that was added with v1.14- The Configuration System! This is means you can configure a project to dis-allow certain features that your team deems unsafe or undesirable. Better yet, it can also create directory specific config with different settings. This is AWESOME.

更新 12（2016 年 2 月 17 日）
在尝试为我目前正在进行的项目引入 Lombok 的理由时，我发现了一块金子v1.14——配置系统！这意味着您可以配置项目以禁止您的团队认为不安全或不受欢迎的某些功能。更好的是，它还可以使用不同的设置创建特定于目录的配置。这太棒了。

UPDATE 13 (Oct 4 '16)
If this kind of thing matters to you, Oliver Gierkefelt it was safe to add Lombok to Spring Data Rest.

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

UPDATE 14 (Sep 26 '17)
As pointed out by @gavenkoain the comments on the OPs question, JDK9 compiler support isn't yet available(Issue #985). It also sounds like it's not going to be an easy fix for the Lombok team to get around.

更新 14（2017年9 月 26 日）
正如@gavenkoa在关于 OP 问题的评论中所指出的，JDK9 编译器支持尚不可用（问题 #985）。这听起来对 Lombok 团队来说也不是一个容易解决的问题。

UPDATE 15 (Mar 26 '18)
The Lombok changelog indicates as of v1.16.20 "Compiling lombok on JDK1.9 is now possible" even though #985is still open.

更新 15（
2018 年3 月 26 日）Lombok 更改日志表明，从 v1.16.20 开始，“现在可以在 JDK1.9 上编译 lombok”，即使#985仍处于打开状态。

Changes to accommodate JDK9, however, necessitated some breaking changes; all isolated to changes in config defaults. It's a little concerning that they introduced breaking changes, but the version only bumped the "Incremental" version number (going from v1.16.18 to v1.16.20). Since this post was about the safety, if you had a yarn/npmlike build system that automatically upgraded to the latest incremental version, you might be in for a rude awakening.

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

UPDATE 16 (Jan 9 '19)

更新 16（2019 年 1 月 9 日）

It seems the JDK9 issues have been resolvedand Lombok works with JDK10, and even JDK11 as far as I can tell.

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

One thing I noticed though that was concerning from a safety aspect is the fact that the change log going from v1.18.2 to v1.18.4 lists two items as BREAKING CHANGE!? I'm not sure how a breaking change happens in a semver "patch" update. Could be an issue if you use a tool that auto-updates patch versions.

尽管从安全方面考虑，我注意到的一件事是，从 v1.18.2 到 v1.18.4 的更改日志将两个项目列为BREAKING CHANGE!? 我不确定在 semver“补丁”更新中是如何发生重大变化的。如果您使用自动更新补丁版本的工具，则可能会出现问题。

回答by sorencito

I know I'm late, but I can't resist the temptation: anybody liking Lombok should also have a look at Scala. Many good ideas that you find in Lombok are part of the Scala language.

我知道我迟到了，但我无法抗拒诱惑：任何喜欢 Lombok 的人也应该看看 Scala。您在 Lombok 中发现的许多好主意都是 Scala 语言的一部分。

On your question: it's definitely easier to get your developers trying Lombok than Scala. Give it a try and if they like it, try Scala.

关于您的问题：让您的开发人员尝试 Lombok 绝对比 Scala 更容易。试一试，如果他们喜欢，试试 Scala。

Just as a disclaimer: I like Java, too!

免责声明：我也喜欢 Java！

回答by Vadzim

Wanted to use lombok's @ToStringbut soon faced random compile errors on project rebuild in Intellij IDEA. Had to hit compile several times before incremental compilation could complete with success.

想使用 lombok 的，@ToString但很快在 Intellij IDEA 中的项目重建中遇到随机编译错误。必须多次点击编译才能成功完成增量编译。

Tried both lombok 1.12.2 and 0.9.3 with Intellij IDEA 12.1.6 and 13.0 without any lombok plugin under jdk 1.6.0_39 and 1.6.0_45.

在 jdk 1.6.0_39 和 1.6.0_45 下没有任何 lombok 插件的情况下，使用 Intellij IDEA 12.1.6 和 13.0 尝试了 lombok 1.12.2 和 0.9.3。

Had to manually copy generated methods from delomboked source and put lombok on hold until better times.

不得不从 delomboked 源手动复制生成的方法并将 lombok 搁置直到更好的时间。

Update

更新

The problem happens only with parallel compile enabled.

该问题仅在启用并行编译时发生。

Filed an issue: https://github.com/rzwitserloot/lombok/issues/648

提出问题：https: //github.com/rzwitserloot/lombok/issues/648

Update

更新

mplushnikov commented on 30 Jan 2016:

Newer version of Intellij doesn't have such issues anymore. I think it can be closed here.

mplushnikov 于 2016 年 1 月 30 日评论：

较新版本的 Intellij 不再有此类问题。我认为它可以在这里关闭。

Update

更新

I would highly recommend to switch from Java+Lombok to Kotlinif possible. As it has resolved from the ground up all Java issues that Lombok tries to work around.

如果可能，我强烈建议从 Java+Lombok 切换到Kotlin。因为它已经从头开始解决了 Lombok 试图解决的所有 Java 问题。

回答by Harun

I'm not recommend it. I used to use it, but then when I work with NetBeans 7.4 it was messing my codes. I've to remove lombok in all of files in my projects. There is delombok, but how can I be sure it would not screw my codes. I have to spends days just to remove lombok and back to ordinary Java styles. I just too spicy...

我不推荐它。我曾经使用过它，但是当我使用 NetBeans 7.4 时，它弄乱了我的代码。我必须在我的项目中的所有文件中删除 lombok。有 delombok，但我怎么能确定它不会搞砸我的代码。我必须花几天时间才能删除 lombok 并恢复到普通的 Java 样式。我就是太辣了...

回答by ChrisA

I haven't tried using Lombok yet - it is/was next on my list, but it sounds as if Java 8 has caused significant problems for it, and remedial work was still in progress as of a week ago. My source for that is https://code.google.com/p/projectlombok/issues/detail?id=451.

我还没有尝试过使用 Lombok - 它是/曾经是我列表中的下一个，但听起来好像 Java 8 已经给它造成了严重的问题，并且截至一周前，补救工作仍在进行中。我的来源是https://code.google.com/p/projectlombok/issues/detail?id=451。