Removing log4j from the IntelliJ Platform
As you no doubt know, several major vulnerabilities have been recently discovered in the version 2 of the log4j library. As we have previously announced, the IDEs based on the IntelliJ Platform are not affected by this vulnerability, because they use a patched version of log4j 1.2 with all network-related code removed. Versions 1 and 2 of the log4j library are two completely different codebases with incompatible APIs, and migrating from one to the other is a non-trivial endeavor with unclear benefits. Despite that, some automated security tools still flag our use of an “old” version of log4j as a security issue.
At the same time, our requirements for a logging framework are fairly minimal; the only features we need are logging to files and the console, as well as the possibility to configure log levels for different parts of the codebase. All of these requirements are covered by the standard logging API available as part of the JDK (java.util.logging), and in order to avoid false security alerts and reduce potential attack surface, we’ve decided to stop using log4j altogether and to switch to java.util.logging as the standard logging framework. The change will be released in version 2022.1.
Since log4j is used (directly or indirectly) by a large number of third-party plugins, we’re going to ship a stub implementation of the log4j APIs redirecting the log output to java.util.logging, taken from the SLF4J project. However, the stub does not completely implement all methods, so in order to maintain full functionality of your plugins, you may need to adapt your code to the new environment.
Please check whether your code or your dependencies use log4j, and follow these instructions to update your code:
- If you use log4j in your own plugin code: Switch to using the standard platform logging API,
- If you use log4j in your own code that is used both in a plugin and in other contexts: Switch to using SLF4J APIs. The IntelliJ Platform ships with an implementation of the SLF4J APIs over java.util.logging, so SLF4J logging is fully supported in the platform.
- If log4j is used in a dependency of your code: Request the dependency maintainer to switch to SLF4J. If that is not possible, logging from the dependency will most likely continue working thanks to the log4j to SLF4J bridge.
- If you use the log4j APIs to customize the logging of your dependency that uses SLF4J: Switch to using the java.util.logging APIs for configuring handlers and log levels.
- If you use log4j XML files to configure logging in your tests: Switch to the configuration using .properties files as described in the LogManager documentation. When running tests using the IntelliJ test framework, the path to the logging properties file can be passed using the
The changes are included in the 221.4165.x EAP builds that will be released this week. Please use those builds for testing the compatibility of your plugins with the platform changes.
Subscribe to Blog updates
Thanks, we've got you!
Busy Plugin Developers Newsletter – Fall 2023
Read this blog post to discover what has come to JetBrains Marketplace this Fall!
JetBrains Marketplace Celebrates 5 Years
Half a decade ago, JetBrains Plugin Repository officially transformed into JetBrains Marketplace. As we celebrate this milestone, we’d like to take this opportunity to reflect on the incredible journey we’ve taken together. TL;DR: Read this blog post to learn how you can join the ongoing celebrat…
Busy Plugin Developers Newsletter – Summer 2023
Read this blog post to discover what has come to JetBrains Marketplace this Summer!
Wayland Support for IntelliJ-based IDEs
For Linux users of IntelliJ-based IDEs, an exciting advancement is on the horizon – the upcoming support of the Wayland display server protocol. This update is set to bring a host of benefits, including solving the age-old fractional scaling problem and elevating desktop integration when working wit…