图片来自Pexels。原文如下：下面结合自己使用Lombok后的感受，谈谈Lombok带来的几大痛点。01JDK版本问题当我想将现有项目的JDK从Java8升级到Java11时，发现Lombok无法正常工作。所以只好把项目源码中所有的Lombok注解全部去掉，使用IDE自带的函数生成getter/setter、equals、hashCode、toString、constructor方法。您还可以使用Delombok工具来完成此过程。但这毕竟会消耗你大量的时间。我的反驳：一旦很多公司确认JDK版本长期不变（比如很多银行项目都在用JDK1.6，你问他愿不愿意升级到JDK11？），现在是版本14.看看有多少公司会升级！比如现在很多公司都在用JDK1.8。如果你去JDK14，我会继续用JDK1.8。到了JDK20，相信Lombok肯定会支持更高的版本。届时将不存在兼容性问题。02强制使用当你在你的源代码中使用了Lombok，而你的代码正好被其他人使用，那么那些依赖你代码的人也必须安装Lombok插件（不管他们喜不喜欢）。了解Lombok注解的使用也需要时间，如果不了解，代码将无法正常运行。在使用了Lombok之后，我发现这是一个非常流氓的行为。我的反驳：装不装Lombok插件，不在于你喜不喜欢。这不是由您的个人意愿决定的。这就是工作，你必须按照公司的要求去做。这是规则。Lombok是一个很简单的知识点，十分钟就能上手，你却抱怨学习需要时间。作为一个程序员，你不是一直在学习吗？如果你有这样的抱怨，你只能放弃程序员的工作！03可读性差Lombok隐藏了JavaBean封装的细节。如果使用@AllArgsConstructor注解，它会提供一个巨大的构造函数，让外界有机会在对象初始化时修改类中的所有属性。首先，这是极不安全的，因为我们不想修改类中的某些属性。另外，如果一个类中有几十个属性，就会有一个构造函数有几十个参数被Lombok注入到类中，这是不合理的行为。其次，构造函数参数的顺序完全由Lombok控制，我们无法控制，只有当你需要调试的时候，你才发现有一个奇怪的“小强”在等着你。最后，在运行代码之前，JavaBean中的所有方法你只能想象它们的样子，你是看不到的。我的反驳：如果你对@AllArgsConstructor不满意，你可以使用@Builder。这支持您以任意顺序创建任意数量的对象。如果不了解Lombok的其他用法，那就不好了。要不要看看JavaBean中的方法？这有什么好？Getter和Setter方法有什么好处？不知道Getter和Setter方法是什么样子的吗？真不明白有什么好？04代码耦合增加当你使用Lombok编写了某个模块的代码后，其他依赖该模块的代码需要引入Lombok依赖，还需要在IDE中安装Lombok插件。Lombok的依赖包虽然不大，但是因为其中一个使用了Lombok，其他所有的依赖都要强制加入Lombok的Jar包。这是一种侵入式耦合。如果再出现JDK版本问题，那就惨了。我的反驳：当我们使用其他框架时，那个框架引入了无数的包，现在我们不得不担心引入一个小包。Lombok太好用了，几乎所有的项目都会用到，这也是需要强制导入的。好吧，我们会在maven的父依赖中有意识地统一引入。05得不偿失使用Lombok，一时觉得很爽，但是污染了你的代码，破坏了Java代码的完整性、可读性和安全性，同时增加了团队的技术债。这是一种得不偿失、得不偿失的操作。如果你真的想让你的代码更简洁，同时兼顾可读性和编码效率，你还不如使用主流的Scala或Kotlin这种基于JVM的语言。我的反驳：破坏诚信？有臃肿的Getter&Setter你嫌弃臃肿，你说不加就破坏代码的完整性，你想干嘛。增加团队的技术债？十分钟学会Lombok，有什么可增加的。你想使用Kotlin吗？大多数公司都没有那么激进，现在Kotlin的很多配套的东西还不成熟，不适合企业使用。作者：Java实用技术编辑：陶嘉龙来源：toutiao.com/i6884399145390440964
