送大家以下 java 学习材料

常常在其它各个中央在说公司禁止应用 Lombok，我始终不明确为什么不让用，明天看到一篇文章列举了一下“毛病”，这里我只想狠狠地反驳，看到列举的理由我竟无言以对。

JDK 版本问题

当我想要将现有我的项目的 JDK 从 Java 8 降级到 Java 11 时，我发现 Lombok 不能失常工作了。于是我不得不将所有的 Lombok 注解从我的项目源代码中革除，并应用 IDE 自带的性能生成 getter/setter，equals，hashCode，toString 以及结构器等办法，你也能够应用 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 的 parent 依赖中对立引入了。

得失相当

应用 Lombok，一时感觉很爽，但它却净化了你的代码，毁坏了 Java 代码的完整性，可读性和安全性，同时还减少的团队的技术债权，这是一种弊大于利，得失相当的操作。如果你的确想让本人的代码更加精炼，同时又兼顾可读性和编码效率，无妨应用支流的 Scala 或 Kotlin 这一基于 JVM 的语言。

我的反驳：毁坏了完整性？加上臃肿的 Getter&Setter 你却厌弃臃肿，不加你又说毁坏代码的完整性，你想怎么做。减少团队的技术债权？学个 Lombok 十分钟的事件，有什么好减少的。要应用 Kotlin? 个别公司都没有这么激进吧，当初 Kotlin 很多配套货色在企业中应用还不成熟吧。

大家还有什么不同观点能够相互探讨。