Fwd: Feedback about StableValues(Preview)
david Grajales
david.1993grajales at gmail.com
Mon Sep 22 21:36:16 UTC 2025
Actually the example I gave would be better implemented with maps than with
lists. Maps offer better readability and don't require dealing with
indexes. Many UI widgets works like that, I suppose many Android developers
will be happy.
I can think of some lazy computing of HttpRequests for IoT scripting.
El lun, 22 sept 2025 a la(s) 9:05 a.m., Maurizio Cimadamore (
maurizio.cimadamore at oracle.com) escribió:
> Thanks,
> and, to clarify -- I meant usage of a map whose keys/values are computed
> lazily, but whose max size is fixed.
>
> Maurizio
> On 22/09/2025 14:40, david Grajales wrote:
>
> Hi maurizio.
>
> I have considered one particular case but not one I would use a lot tho.
>
> When you are developing some UI or frontend like content and you have a
> view that requires the loading from multiple external sources (for example
> weather information and maps information) doing from a list of tasks lazily
> may be helpful. Not something I would use i my day by day work, I am mostly
> a pure server side developer (mostly backend and IoT); haven't done
> anything related to UI recently.
>
>
>
> El lun, 22 sept 2025 a la(s) 7:25 a.m., Maurizio Cimadamore (
> maurizio.cimadamore at oracle.com) escribió:
>
>> Picking up on this old thread again
>>
>> On 03/09/2025 00:54, david Grajales wrote:
>> > So, in short the stable values are not mean for very dynamic scenarios
>> > because the API prioritize performance and efficiency at runtime and
>> > sacrifices flexibility in exchange; which translates as " the keys or
>> > at least the size of the stableValue must be know at compile time".
>>
>> Asking more directly -- could you see cases where specifying just a size
>> (instead of the full set of keys) could be more flexible in some of the
>> use cases you have considered?
>>
>> Maurizio
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250922/8c68486b/attachment.htm>
More information about the amber-dev
mailing list