Why JetBrains Dropped Log4j from IntelliJ: Lessons for Plugin Developers

This morning, DD noticed JetBrains announced on its official blog that it will remove Log4j from the IntelliJ platform, with the change slated for the 2022.1 release.

From the blog post, the removal of the Log4j vulnerability is not due to concerns about Log4j2, because IDEs built on the IntelliJ platform use a patched version of Log4j 1.2 (with all network‑related code removed). DD also checked the earlier announcements during the Log4j critical vulnerability outbreak, and according to the official notice, many of its development‑tool products were not affected.

The decision to remove Log4j is mainly because the IntelliJ platform IDEs have very low logging requirements (only need to log information to files and console), and Log4j is overly complex (it can directly or indirectly introduce many third‑party components). To avoid future potential issues, the dependency on Log4j will be removed.

Impact Scope

Removing Log4j from development tools has little impact on most developers, but plugin developers may be affected. Therefore, the official guidance includes:

If you use Log4j in your own plugin code: switch to the standard platform logging API com.intellij.openapi.Diagnotic.Logger .

If you use Log4j in your own code that can be used in plugins and other contexts: switch to the SLF4J API. The IntelliJ platform provides an implementation of SLF4J via java.util.log , so the platform fully supports SLF4J logging.

If Log4j is used in a dependency of your code: ask the dependency maintainer to switch to SLF4J. If that is not possible, the Log4j‑to‑SLF4J bridge may allow logging to continue.

If you customize logging of SLF4J‑dependent dependencies using the Log4j API: switch to using java.util.logingAPI to configure handlers and log levels.

If you use a Log4j XML file to configure logging in tests: switch to using a .properties file as described in the LogManager documentation. When running tests with the IntelliJ test framework, you can pass the path to the logging properties file via the system property idea.log.config.properties .

DD believes that for a product like IntelliJ, removing Log4j is a valuable lesson; as the official statement says, Log4j is overly complex and brings many features that are not useful, which can cause hidden risks. Beyond security concerns, dependency‑management issues often arise from complex high‑level dependencies, as DD has frequently observed when helping other developers troubleshoot.

Finally, a question for everyone: Which of the six principles of object‑oriented design does JetBrains' decision align with? Leave your answer in the comments!