(maven) 01/06: Address review: document LOGGER_CACHE as intentionally unbounded in MavenJulHandler

[gn...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

gnodet pushed a commit to branch feature/logging-foundation-work
in repository https://gitbox.apache.org/repos/asf/maven.git

commit 1fe9484acf38d74fa9ea41a1a97da9b6a32dffcc
Author: Guillaume Nodet <gn...@apache.org>
AuthorDate: Wed Sep 23 06:13:00 2026 +0000

    Address review: document LOGGER_CACHE as intentionally unbounded in MavenJulHandler
---
 .../src/main/java/org/apache/maven/slf4j/MavenJulHandler.java      | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/impl/maven-logging/src/main/java/org/apache/maven/slf4j/MavenJulHandler.java b/impl/maven-logging/src/main/java/org/apache/maven/slf4j/MavenJulHandler.java
index 747accaf51..0ea7093dc5 100644
--- a/impl/maven-logging/src/main/java/org/apache/maven/slf4j/MavenJulHandler.java
+++ b/impl/maven-logging/src/main/java/org/apache/maven/slf4j/MavenJulHandler.java
@@ -80,6 +80,13 @@ public record JulMetadata(String sourceClassName, String sourceMethodName, long
      * {@code ConcurrentHashMap} throws.  {@code putIfAbsent} is safe
      * against reentrancy — worst case, two threads create the same
      * logger and one is discarded.
+     * <p>
+     * The cache is intentionally unbounded: its size is naturally bounded
+     * by the number of distinct JUL logger names observed across all builds
+     * in a JVM lifetime, which is small in practice (a few dozen at most).
+     * In long-running daemon processes this set grows monotonically but
+     * never exceeds the set of all distinct logger names used by the JUL
+     * frameworks active in the build environment.
      */
     private static final ConcurrentMap<String, org.slf4j.Logger> LOGGER_CACHE = new ConcurrentHashMap<>();