今早，DD注意到JetBrains在官方博客发文宣布要将log4j从IntelliJ平台移除了，该变化将在2022.1版本发布。

从博文看，本次移除log4j的漏洞，并非担心log4j2的漏洞问题，因为基于IntelliJ平台的IDE使用的并非log4j2，而是log4j 1.2的补丁版本（移除了所有网络相关的代码）。这里DD也顺便看了一下，之前log4j核弹漏洞大爆发时候的消息，根据官方给出的公告看，其旗下大量开发工具类产品并不受影响。

此次决定将log4j移除，核心还是因为IntelliJ平台的IDE其实对于日志的需求非常低（仅用来信息到文件和控制台），而log4j太过于复杂（会直接或间接引入太多第三方内容）。为了避免未来出现其他潜在的问题，所以将移除对log4j的依赖。

从开发工具中移除log4j其实对大部分开发者影响不大，但如果你是插件开发者，那么会受一些影响。所以，官方给出了一些建议：

• 如果您在自己的插件代码中使用log4j：切换到使用标准平台日志记录APIcom.intellij.openapi.Diagnotic.Logger
• 如果您在自己的代码中使用log4j，该代码在插件和其他上下文中都可以使用：请切换到使用SLF4J API。IntelliJ平台通过java.util.log附带了SLF4J API的实现，因此该平台完全支持SLF4J日志记录。
• 如果在代码的依赖项中使用log4j：请求依赖项维护者切换到SLF4J。如果这是不可能的，多亏了log4j到SLF4J桥，从依赖项进行的日志记录很可能会继续工作。
• 如果您使用log4jAPI定制使用SLF4J的依赖项的日志记录：切换到使用java.util.logingAPI来配置处理程序和日志级别。
• 如果您在测试中使用log4jXML文件来配置日志记录：请切换到使用.properties文件的配置，如LogManager文档中所述。使用IntelliJ测试框架运行测试时，可以使用idea.log.config.properties文件系统属性传递日志属性文件的路径。

DD觉得对于IntelliJ这样的产品来说，移除log4j还是非常值得我们学习的，正如官方所说的那样，log4j过于复杂，会引入很多其他东西，而这些东西带来的特性对自己有没啥用，确实会造成一些隐患。不提安全问题吧，就依赖管理上，DD以前帮其他开发查问题的时候，经常发现的依赖冲突大多就是引入了一些复杂的高级依赖形成的。

最后，考考大家，JetBrains这一决定，符合面向对象设计六大原则中的哪一个原则？留言说出你的答案！

我们创建了一个高质量的技术交流群，与优秀的人在一起，自己也会优秀起来，赶紧点击加群，享受一起成长的快乐。