JetBrains announces: IntelliJ platform completely decommissions Log4j components, it is recommended to switch to java.util.logging

Recently, the official blog of JetBrains announced that the IntelliJ platform will completely stop using Log4j, and it is recommended to switch to java.util.logging as the standard logging framework.

According to JetBrains, although the platform has fairly low requirements for the logging framework, it still requires logging to a file and console, and the possibility to configure log levels for different parts of the codebase. The standard logging API that is part of the JDK (java.util.logging) covers all these requirements.

Therefore, in order to avoid false security alerts and reduce the potential attack surface, JetBrains has officially decided to stop using Log4j entirely and instead use java.util.logging as the standard logging framework (this change will be released in version 2022.1).

JetBrains mentioned in their blog post that since a large number of third-party plugins (directly or indirectly) use Log4j, they will provide a stub implementation of the Log4j API that redirects log output to java.util.logging (taken from the SLF4J project). Of course, the stubs do not yet fully implement all methods, so in order to maintain the full functionality of the plugin, the user may need to adapt the code to the new environment.

In this regard, JetBrains official also attached some update suggestions for users (check whether the code or dependencies use Log4j to update the code according to the following instructions):

• If you are using Log4j in your own plugin code: switch to using the standard platform logging API com.intellij.openapi.diagnostic.Logger
• If you are using Log4j in your own code, and that code is used in plugins and other contexts: switch to using the SLF4J API. The IntelliJ platform ships with the SLF4J API implemented through java.util.logging, so the platform fully supports SLF4J logging.
• If using Log4j in your code's dependencies: Ask the dependency maintainer to switch to SLF4J. If that doesn't work, it's implemented through the Log4j-SLF4J logging bridge, and logging from dependencies continues to work.
• If you customize logging using SLF4J dependencies through the Log4j API, switch to the logging API that uses java.util.logging to configure handlers and log levels.
• If using a Log4j xml file to configure logging in tests: use switch to configure using a properties file as described in the LogManager documentation. The path to the idea.log.config.properties.file system property can be used when running tests with the IntelliJ test framework.

These changes are present in the upcoming 221.4165.x EAP release (recommended to use these releases to test plugin compatibility with platform changes).

As we all know, at the end of last year, several major vulnerabilities were exposed in Log4j2, and then JetBrains officially announced that they were using the patched version of Log4j 1.2, so IDEs based on the IntelliJ platform were not affected by this vulnerability, and deleted all connections with the network. related code.

It is reported that version 1 and version 2 of the Log4j library are two completely different code bases, and because the two have incompatible APIs, it is not easy to migrate from one version to another. Still, some automated security tools flag JetBrains' use of an "old" version of Log4j as a security issue.

This change will also completely cut off users' concerns about JetBrains' security issues. For this change, if you have any opinions, you are welcome to exchange and interact in the comment area.

Reference link: https://blog.jetbrains.com/platform/2022/02/removing-log4j-from-the-intellij-platform/