Maintenance: Consider Using System.Logger as Facade

[AdamBien]

Summary

Java 9 introduced a logging façade, which can be used instead of third-party logging solutions: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System/Logger.html. The default implementation is java.util.logging.

Why is this needed?

Using Java's built-in functionality reduces deployment size, lowers startup time, and eliminates vulnerability risks caused by external dependencies.

Which area does this relate to?

Logger

Solution

https://github.com/AdamBien/aws-quarkus-lambda-http-api-cdk-plain/blob/main/lambda/src/main/java/airhacks/lambda/greetings/boundary/GreetingResource.java

Acknowledgment

• This request meets Powertools for AWS Lambda (Java) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, TypeScript

[sdangol]

Hi @AdamBien, thanks for creating the issue. One of our Java engineers will get back to you soon.

[phipag]

Thanks for opening this issue @AdamBien. I had a brief look at System.Logger to understand how this integrates with the logging implementations that we support today (logback and log4j2).

For logback, I found a reference implementation for a bridge from System.Logger -> SLF4J API -> Logback here: https://github.com/qos-ch/slf4j/tree/master/slf4j-jdk-platform-logging.

For Logj42, I couldn't find any official implementations.

However, since your primary motivation here is to remove the external dependency on SLF4J API, we shouldn't bridge through SLF4J.

One path forward might be to implement our own java.lang.System.LoggerFinder bridge and expose it through META-INF/services/java.lang.System$LoggerFinder for the service loader in System.Logger to load. This way, we can bridge directly from System.Logger to logback / log4j2 which contains the structured logging logic and other features such as log buffering provided by Powertools.

This issue requires more scoping because we need to understand in more detail the differences between what SLF4J API can offer vs. System.Logger. For example, we use the SLF4J MDC to propagate logging context in a thread-safe way which is unclear how this translates to System.Logger.

We also need to understand the impact on our structured arguments implementation. For example:

// Single structured argument
LOGGER.info("Processing order {}", order.getOrderId(), entry("order", order));

// Context enrichment through MDC
MDC.put("cardNumber", card.getId());
LOGGER.info("Updating card information");  // JSON will contain cardNumber key value

– https://docs.aws.amazon.com/powertools/java/latest/core/logging/#custom-keys

[phipag]

We will keep this issue as an idea for now to understand the customer interest. Please 👍 this issue to show your interest.