That's totally fair and what I expected.
Maybe the if(x.isBound()) return x.get() could be made more performant, and I suppose somewhere the docs could mention using a NullObject pattern is a useful approach. -Michael Sent from Mailspring (https://link.getmailspring.com/link/[email protected]/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=bG9vbS1kZXZAb3Blbmpkay5vcmc%3D), the best free email app for work On Feb 23 2026, at 9:49 am, Alan Bateman <[email protected]> wrote: > > > On 23/02/2026 14:18, Michael Stover wrote: > > I've been using Scoped Values heavily for some time for a variety of > > things and just thought I'd share a couple thoughts . I'm currently > > using JDK 25. > > > > First, really simply, the ScopedValue.get() method throws a runtime > > exception if the value is not bound. Ok, kind of like Optional. But, > > it seems ScopedValue.orElse(null) also throws a runtime exception, > > which makes it awkward to safely get the currently scoped value or > > null. Instead we have to do: > > > > if(scopedValue.isBound()) return scopedValue.get(); > > else return null; > > > > Or use a static NullObject pattern. If we give orElse() a new Object, > > we're creating that new object every time regardless of whether it's > > needed. So, calling isBound() all the time seems overly verbose and > > tedious, and it appears to be a bit of a performance hit from my > > testing as well, as it's an expensive operation, and I guess we're now > > doing it twice. > > > > So I think that could be improved so one can get a null out, or at > > least give us an idiom that isn't a performance drag. > > > > Using a sentinel value, like your NullObject, should be okay. > orElse(T) is specified to reject null to allow it be compatibly changed > to T! in the future. > > -Alan
