Fwd: Feedback about StableValues(Preview)

[david Grajales]

---------- Forwarded message ---------
De: david Grajales <david.1993grajales at gmail.com>
Date: lun, 1 sept 2025 a la(s) 8:43 p.m.
Subject: Feedback about StableValues(Preview)
To: <core-libs-dev at openjdk.org>


Subject: Feedback and Questions on JEP 8359894 - Stable Values API

Dear Java core-libs development team,

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.

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.


Current Implementation

Currently, I have a logging utility that follows a standard pattern for
lazy value computation:

class DbLogUtility {
    private static final ConcurrentMap<String, Logger> loggerCache = new
ConcurrentHashMap<>();

    private DbLogUtility(){}

    private static Logger getLogger() {
        var className =
Thread.currentThread().getStackTrace()[3].getClassName();
        return loggerCache.computeIfAbsent(className,
LoggerFactory::getLogger);
    }
    public static void logError(){
        //.... implementation detail
    }
}

Challenge with Stable Values API

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 (StableValue.function(Set<K>,
Function) and StableValue.intFunction(int, IntFunction)) expect predefined
key sets or bounded integer ranges.

This design constraint makes it challenging to handle dynamic key discovery
scenarios, which are quite common in enterprise applications for:

   - Logger caching by dynamically discovered class names
   - Configuration caching by runtime-determined keys
   - Resource pooling with dynamic identifiers
   - Etc.


Questions and Feedback

   1. *Am I missing an intended usage pattern?* Is there a recommended
   approach within the current API design for handling dynamic key discovery
   while maintaining the performance benefits of stable values?
   2.  Would you consider any of these potential enhancements:
      - 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)
      - A hybrid approach that provides stable value benefits for
      dynamically discovered keys
   3. 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?

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.

Best regards, and always yours.

David Grajales Cárdenas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250901/5e4daab1/attachment.htm>