Java Logging has always been a crucial topic in software development. However, the existence of multiple logging APIs has led to developers' debates about which to use. This often requires additional configuration to include or exclude certain frameworks and bridges to redirect log messages between different APIs. Major OSS projects like Netty, Reactor, and JUnit have even developed their own logging APIs to remain API agnostic and avoid incompatibilities that can arise from upgrades to popular APIs.
The recent Log4Shell vulnerability highlighted the critical need for minimizing dependencies in software projects. Using bridges and complex configurations can increase security risks, making it essential to streamline and standardize logging practices.
A unified logging standard within Jakarta EE could address these issues, promoting security and simplicity in Java development.
The project establishes a standard for Logging APIs within Jakarta EE, aiming to unify and simplify logging practices across the Java ecosystem. It does not implement logging functionality itself but draws on best practices and widely accepted conventions among developers. The design will be inspired by established APIs such as SLF4J and Log4j, ensuring familiarity and ease of adoption for the community.
Both Log4j and SLF4J contain legacy elements that are outdated by modern standards. This project aims to distill the most effective features from both APIs. A new Jakarta Logging API will be modern, user-friendly, and efficient. The goal is to make upgrading to the Jakarta Logging API straightforward, ensuring that it feels familiar to current users while providing improved functionality and simplicity.
There are no known issues.
The Eclipse Foundation is a natural choice for hosting this project as it already oversees Jakarta EE, which includes widely adopted standards like JPA. Introducing a logging standard within Jakarta EE would be natural and will benefit the entire community. Developing this standard under the Eclipse Foundation rather than the ASF also highlights its independence and neutrality from existing open-source projects.
We plan to work on this project right after acceptance. With our team's solid experience in API design, we'll be able to put forward initial proposals quickly. While we expect some lively discussions around the topic, it's not overly complex, so we aim to have the first release out within 12 months.
We do not yet have any code ready. However, since we model the API after existing projects, the Log4j code base can be an example. Since it the project will be rewritten in full, there are no copyright issues.
- Log in to post comments
Java Platform Logging?
Submitted by David Matějček on Sat, 10/12/2024 - 16:16
Would not be better to just adopt System.Logger? GlassFish already started using it. System.Logger is also supported by SLF4J and other modern frameworks too, so implementations can easily switch.
If we would talk about formats - GlassFish supports old Oracle's ODL and Uniform formats, my idea is to add some industry standard used ie. in Linux syslog file - btw GlassFish supports also SysLog service since around 2003, this standard is here for years in several generations. SLF4J supports it too.
I am not sure if inventing another standard is worth of the effort, but maybe I just don't know your motivation. And also it sounds suspicious to me that you didn't mention Java Util Logging, and System.Logger (aka Java Platform Logging) which is here since Java 9.
GlassFish7 uses its own Log Manager based on JUL with around 90% test code coverage to allow high throughput under heavy load and allowing two phase initialization (because Java starts using it before GlassFish loads configuration).
Sum - I would like to know some important features contrasting with what is already supported in existing implementations. In few points.