送你以下java学习资料。我经常说公司禁止在其他各种地方使用Lombok。我一直不明白为什么不允许他们使用它。今天看到一篇文章，列举了“缺点”。在这里我只想狠狠反驳一下，看到罗列的理由，我无语了。JDK版本问题当我想将现有项目的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肯定会支持更高的版本，那么兼容性问题就不存在了。强制使用当你在你的源代码中使用Lombok，而你的代码正好被其他人使用，那么那些依赖你代码的人也必须安装Lombok插件（不管他们喜欢与否），并花时间去了解Lombok注释的使用，如果你不这样做，你的代码将无法工作。在使用了Lombok之后，我发现这是一个非常流氓的行为。我的反驳：装不装Lombok插件不是你喜不喜欢的事情。这不是由您的个人意愿决定的。这是工作，你必须按照公司的要求去做。Lombok是一个很简单的知识点，你十分钟就能上手，你却抱怨学习需要时间。作为一个程序员，你不是一直在学习吗？如果你有这样的抱怨，你只能放弃程序员的工作！可读性差Lombok隐藏了JavaBean封装的细节。如果使用@AllArgsConstructor注解，它会提供一个巨大的构造函数，让外界有机会在对象初始化时修改类中的所有属性。首先，这是极不安全的，因为我们不想修改类中的某些属性；另外，如果一个类中有几十个属性，就会有一个包含几十个参数的构造函数被删除。Lombok将其注入到类中，这是不合理的行为；其次，构造函数参数的顺序完全由Lombok控制，我们无法控制，只有当你需要调试的时候，你才发现有一个奇怪的“小强”在等着你；最后，在运行代码之前，所有的JavaBean中的方法你只能想象它们的样子，你是看不到的。我的反驳：如果你对@AllArgsConstructor的做法不满意，你可以使用@Builder。这支持您以任意顺序和任意数量创建对象。如果不了解Lombok的其他用法，那就不好了。你想看看JavaBean中的方法吗？有什么好啊，getter和setter方法有什么好啊，难道你不知道getter和setter方法长啥样吗？真不明白这有什么好？增加代码耦合当你使用Lombok编写某个模块的代码时，其他依赖该模块的代码需要引入Lombok依赖，同时你还需要在IDE中安装Lombok插件。Lombok的依赖包虽然不大，但是因为其中一个使用了Lombok，其他所有的依赖都要强制加入Lombok的Jar包。这是一种侵入式耦合。如果再出现JDK版本问题，那就惨了。我的反驳：当我们使用其他框架时，那个框架引入了无数的包，现在我们不得不担心引入一个小包。Lombok太好用了，几乎所有的项目都会用到它，需要强制导入。好吧，我们会在maven的父依赖中有意识地统一引入。使用Lombok得不偿失，一时觉得爽，但污染了你的代码，破坏了Java代码的完整性、可读性和安全性，同时也增加了团队的技术债。这是一种弊大于利的做法。毫无价值的操作。如果你真的想让你的代码更简洁，同时兼顾可读性和编码效率，你还不如使用主流的Scala或Kotlin这种基于JVM的语言。我的反驳：违反诚信？加个臃肿的Getter&Setter你嫌弃臃肿，你说不加就破坏代码的完整性，你想干什么。给你的团队增加技术债务？十分钟学习Lombok可以加什么。你想使用Kotlin吗？大多数公司都没有那么激进，对吧？现在Kotlin的很多配套的东西还不够成熟，不能用于企业。大家有不同的意见可以互相讨论。
