This morning, DD noticed that JetBrains announced on the official blog that log4j will be removed from the IntelliJ platform, and this change will be released in version 2022.1.
From the blog post, the log4j vulnerability is removed this time, not because of the log4j2 vulnerability problem, because the IDE based on the IntelliJ platform does not use log4j2, but the patch version of log4j 1.2 (removed all network-related code). DD also took a look here. The previous news of the log4j nuclear bomb vulnerability broke out. According to the official announcement, a large number of its development tool products were not affected.
The core of the decision to remove log4j this time is because the IDE of the IntelliJ platform actually has very low requirements for logs (only used for information to files and consoles), and log4j is too complicated (it will directly or indirectly introduce too much third-party content ). To avoid other potential problems in the future, the dependency on log4j will be removed.
Sphere of influence
Removing log4j from the dev tools doesn't really affect most developers, but if you are a plugin developer, you will be affected. Therefore, the official gave some suggestions:
- If you are using log4j in your own plugin code: switch to using the standard platform logging API
com.intellij.openapi.Diagnotic.Logger
- If you're using log4j in your own code that works in plugins and other contexts: switch to using the SLF4J API. The IntelliJ platform ships with an implementation of the SLF4J API via
java.util.log
, so the platform fully supports SLF4J logging. - If you use log4j in your code's dependencies: Ask the dependency maintainer to switch to SLF4J. If this is not possible, logging from dependencies will most likely continue to work thanks to the log4j to SLF4J bridge.
- If you use log4jAPI to customize logging for dependencies that use SLF4J: Switch to using
java.util.logingAPI
to configure handlers and log levels. - If you are using a log4jXML file to configure logging in your tests: switch to a configuration that uses the
.properties
file, as described in the LogManager documentation. When running tests with the IntelliJ test framework, the path to the log properties file can be passed using theidea.log.config.properties
filesystem property.
DD thinks that for products like IntelliJ, it is worth learning to remove log4j. As the official said, log4j is too complicated and will introduce many other things, and the features brought by these things are of no use to me. , does cause some hidden dangers. Let's not mention security issues, but in terms of dependency management, when DD used to help other developers to check problems, most of the dependency conflicts that were often found were formed by the introduction of some complex advanced dependencies.
Finally, to test everyone, JetBrains' decision conforms to which of the six principles of object-oriented design? Leave a message to say your answer!
We have created a high-quality technical exchange group . When you are with excellent people, you will become better yourself. Quickly click on to join the group and enjoy the joy of growing together.
Welcome to my public account: Programmer DD. Learn about cutting-edge industry news for the first time, share in-depth technical dry goods, and obtain high-quality learning resources
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。