[External] : Re: Feedback about LazyConstants API (JEP526)

[Anatoly Kupriyanov]

My idea is not an optional *interface*, but an interface for something
which is convertible to the Optional *type*. In other words, neither the
LazyConstant nor to ScopedVariable *is not* an optional itself, but could
be converted to it uniformly.
Something like this:

interface Optionable<T> {// need to think about the better naming!
  T orElse(T other);

   // and maybe even:
   default Optional<T> asOptional() {
    return Optional.ofNullable(this.orElse(null));
   };
}

and then LazyConstant, ScopedVariable, etc could just implement the
interface to unify on the notion of "return a user-provided value
if some condition isn't met". Sounds like a decent path to abolish nulls.

But I feel I am overthinking this...


On Tue, 9 Dec 2025 at 13:35, Red IO <redio.development at gmail.com> wrote:

> I initially thought I agree with your statement that orElse is a common
> pattern in the jdk. But then I failed to come up with a second example. I
> then searched the jdk github repo for the method. And I only found Optional
> and it's specializations and ClassHierarchyResolver.
> So I would suggest yes, it's an often used method ... of the Optional
> class. Not many apis seem to expose it. The case of exposing an accessor
> that returns an Optional on the other hand is incredibly common across the
> jdk. This is exactly the case Optional was designed for. In this sense
> Optional is the "Interface" you are suggesting.
>
> My main argument against reusing orElse here is that the context is a
> completely different one.
> An Optional orElse method is a pure function that always returns the same
> value. It signals that the value is not there.
> LazyConstant is different in this regard. The LazyConstant orElse is not
> pure at all. It depends on rather someone else already initialized the
> value or not. It signals that the value is not there YET.
>
> Great regards
> RedIODev
>
>
>
> On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov <kan.izh at gmail.com> wrote:
>
>> Right, the ScopedValue is another good example I've forgotten. In that
>> case I am even more inclined to keep the `orElse` as it looks like a
>> repeating pattern across JDK libraries. Consistency is the way to go!
>> And maybe even consider having a new interface for the method to make
>> this pattern explicit?..
>>
>> I am glad that `orElseSet` is removed, the side-effecting is bad; also in
>> other parts of JDK we already have `computeIfAbsent` for the same idea. I
>> did not hear about it, and yeah, sounds like the source of this confusion.
>>
>>
>> On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>>>
>>> On 09/12/2025 11:59, Anatoly Kupriyanov wrote:
>>> > To be honest, I don't really see why this method causes such confusion.
>>>
>>> In part I agree. E.g. when we added this, what we had in mind was just
>>>
>>>
>>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T)
>>>
>>> E.g. other APIs have `orElse` method that return a user-provided value
>>> if some condition isn't met.
>>>
>>> I believe the problem we're discussing here is likely also related to
>>> the fact that the API used to have a side-effecting `orElseSet`, which
>>> is now removed, and I wonder if, because of that, folks are reading too
>>> much into what orElse does?
>>>
>>> Maurizio
>>>
>>>
>>
>> --
>> WBR, Anatoly.
>>
>

-- 
WBR, Anatoly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251209/71bb8f3c/attachment-0001.htm>