<div dir="ltr"><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>De: <strong class="gmail_sendername" dir="auto">david Grajales</strong> <span dir="auto"><<a href="mailto:david.1993grajales@gmail.com">david.1993grajales@gmail.com</a>></span><br>Date: lun, 1 sept 2025 a la(s) 8:43 p.m.<br>Subject: Feedback about StableValues(Preview)<br>To:  <<a href="mailto:core-libs-dev@openjdk.org">core-libs-dev@openjdk.org</a>><br></div><br><br><div dir="ltr"><p>Subject: Feedback and Questions on JEP 8359894 - Stable Values API</p>
<p>Dear Java core-libs development team,</p>
<p>Please accept my sincere gratitude and compliments for your ongoing dedication to improving the Java platform. The continuous innovation and thoughtful evolution of Java is truly appreciated by the developer community.</p>
<p>I have been experimenting with the Stable Values API (JEP 8359894) in a development branch of a service at my company, and I would like to share some observations and seek your guidance on a particular use case.</p><p><br></p><h2>Current Implementation</h2><p>
</p><p>Currently, I have a logging utility that follows a standard pattern for lazy value computation:</p><div><br></div><div>class DbLogUtility {<br>    private static final ConcurrentMap<String, Logger> loggerCache = new ConcurrentHashMap<>();<br>    <br>    private DbLogUtility(){}<br><br>    private static Logger getLogger() {<br>        var className = Thread.currentThread().getStackTrace()[3].getClassName();<br>        return loggerCache.computeIfAbsent(className, LoggerFactory::getLogger);<br>    }<br>    public static void logError(){<br>        //.... implementation detail<br>    }</div><div>}</div><div><br></div><div><h2>Challenge with Stable Values API</h2>
<p>When attempting to migrate this code to use the Stable Values API, I encountered a fundamental limitation: the API requires keys to be known at compile time. The current factory methods (<code>StableValue.function(Set<K>, Function)</code> and <code>StableValue.intFunction(int, IntFunction)</code>) expect predefined key sets or bounded integer ranges.</p>
<p>This design constraint makes it challenging to handle dynamic key discovery scenarios, which are quite common in enterprise applications for:</p>
<ul>
<li>Logger caching by dynamically discovered class names</li>
<li>Configuration caching by runtime-determined keys</li>
<li>Resource pooling with dynamic identifiers</li>
<li>Etc.</li></ul></div><div><br></div><div><h2>Questions and Feedback</h2>
<ol>
<li><strong>Am I missing an intended usage pattern?</strong> Is there a recommended approach within the current API design for handling dynamic key discovery while maintaining the performance benefits of stable values?</li>
<li> Would you consider any of these potential enhancements:<ul>
<li>Integration of stable value optimizations directly into existing collection APIs (similar to how some methods have been added to List and Map interfaces for better discoverability)</li>
<li>A hybrid approach that provides stable value benefits for dynamically discovered keys</li>
</ul>
</li>
<li>Do you envision the Stable Values API as primarily serving compile-time-known scenarios, with dynamic use cases continuing to rely on traditional concurrent collections?</li></ol><div><p>Thank you for your time and consideration. I would be grateful for any guidance or clarification you might provide on these questions. If there are planned enhancements or alternative patterns I should consider, I would very much appreciate your insights.</p>
<p>Best regards, and always yours. </p><p>David Grajales Cárdenas. </p></div></div><div><br></div></div>
</div></div>