Record fields cannot be lazily initialized. The point of StableValue is lazy initialization, meaning that their value is stable if and only if they carry a non-default value (i.e. after initialization). If you don’t need lazy initialization, you can just use a regular final field. For a non-final field, without StableValue the JIT optimizer can’t tell if it is stable or not.

The implementation of a value object will be able to use StableValue internally for lazy computation and/or caching of derived values.

I don't know, these are mostly uninformed guesses, but the distinction between Records and Value objects is that the contents lack object identity.

Which, to me, means, potentially, two things.

One, that the JVM can de-dup "anything", like, in theory, it can with Strings now. VOs that are equal are the same, rather than relying on object identity.

But, also, two, it can copy the contents of the VO to consolidate them into a single unit.

Typically, Java Objects and records are blobs of pointers. Each field pointing to something else.

With Value Objects that may not be the case. Instead of acting as a collection of pointers, a VO with VOs in it may more be like a C struct containing structs itself -- a single, continuous block of memory.

So, an Object is a collection of pointers. A Record is a collection of immutable pointers. A Value Object is (may be) a cohesive, contiguous block of memory to represent its contents.

Handwavy explanation: A stable value is used as a static constant, with the difference being that you can initialize it at runtime. Once initialized it is treated as fully constant by the JVM. It's similar to something like lateinit in Kotlin, except on the JVM level.

Records are also immutable, but you can create them and delete them throughout your application like you would a regular class.

> used as a static constant

Yes, but remind people it's not static in the sense of being associated with the class, nor constant for compile-time purposes.

Perhaps better to say: A stable value is lazy, set on first use, resulting in pre- and post- initialization states. The data being set once means you cannot observe a data change (i.e., appears to be immutable), but you could observe reduction in resource utilization when comparing instances with pre-set or un-set values -- less memory or time or other side-effects of value initialization.

So even if data-immutable, a class with a stable value ends up with behavior combinations of two states for each stable value. Immutable records or classes without stable values have no such behavior changes.

But, writ large, we've always had this with the JVM's hotspot optimizations.

For String, it becomes significant whether hashcode is used when calculating equals (as a fast path to negative result). If not, one would have two equal instances that will behave differently (though producing the same data), at least for one hashcode-dependent operation.

Right. Oracle should reconsider the naming here: stable -> lazy

But this is also achievable with static init methods on records and value classes, right?

  record Rational(int num, int denom) {
      Rational {
          int gcd = gcd(num, denom);
          num /= gcd;
          denom /= gcd;
      }
  }

How would you do the same thing with the late initialization of, say, a HashMap where you don't control the constructor?

Hmm, I see what you're saying -- yeah, this seems to be semantically identical to Kotlin's `lateinit` then

Exactly. AFAICT this will be optimized at the JVM level though, so once you've initialized the constant the JIT compiler can take full advantage of that fact.

So every time you take the hash of a string you leak 4 bytes of memory???

I assume it's static in the context of it's containing object. So, it will be collected when it's string is collected.

No. The string hash is stored as part of the String object. It is initialized to 0 but gets set to the real hash of the string on first call to hashCode()

(which is why it will be computed over and over again if your special string happens to hash to 0)

> It's similar to something like lateinit in Kotlin, except on the JVM level.

What level are you suggesting lateinit happens at if not on the JVM?

I assume they mean this feature is built into the JVM itself, whereas Kotlin's lateinit more or less "just" desugars into code you could otherwise write yourself.

A stable value, as I understand it, is either not-yet-computed or is constant. In other words, once computed it’s constant and the JIT can therefore treat it as constant.

It's a much-needed idea but... such an awkward way to do it. Only Java would be okay with an actual language feature using words like "orElseGet". And personally I suspect there's an inverse correlation between feature usage and how semantically awkward it is... it just feels like a mistake to even consider using an inelegant feature unless it's out of complete necessity.

It should really be something like

    public stable logger = () -> new Logger(/* .. */).

Where the JDK hides the details of making sure the value is only created once, basically like the classholder idiom but under the hood. I'm sure there are reasons why they're not doing it that way, but ... it's definitely what the language needs to be able to do.

Incidentally, I've always appreciated for python PEPs how they list all of the obvious complaints about an issue and explain methodically why each was determined not to work. The JEPs don't seem to reach quite the same candor.

In Java, constants are declared as static final.

  static final Complex CONSTANT = new Complex(1, 2);

If you want a lazy initialized constant, you want a stable value

  static final StableValue<Complex> STABLE_VALUE = StableValue.of();

  Complex getLazyConstant() {
    return STABLE_VALUE.orElseGet(() -> new Complex(1, 2))
  }

If you want the fields of a constant to be constant too, Complex has to be declared has a record.

- StableValue is about defining when and how to lazily initialy a field, with strong "exactly-once" semantics. The kinds of things we would do with safe double-checked locking before, but more convenient. Using a record doesn't address that, though you could certainly put a record in a StableValue.

Additionally, having to define a record FooHolder(Foo foo) simply to hold a Foo would be a lot more cumbersome than just saying StableValue<Foo> fooHolder = StableValue.of(); There's no need for an extra type.

- Value classes have no identity, which means they can't have synchronized methods and don't have an object monitor. While it would be possible to store a value object inside a StableValue, there are plenty of use cases for an identity object inside a StableValue, such as the Logger example inside the JEP: one could easily imagine a fictional logger having a synchronized method to preserve ordering of logs.

I wouldn't say these are all entirely orthogonal concerns, but they are different concepts with different purposes.

I've just tried to change a field of an instance of a record using reflection, and it's not possible, even with setAccessible(true).

ooops, my bad. I remember, that Aleksey Shipilëv explained why even `final static` fields are not constant-folded by JIT, and thought that record classes which were introduced later, is the same.

It means, that `StableValue<>` can be used in simple classes (where `final` fields are still not constant-folded) and, additionally, supports late initialization.

Yeah the Java team took the opportunity while introducing the new record feature to explicitly forbid mutating their final fields. Their intention is to eventually enforce the same invariants across all Java fields unless the JVM is passed an explicit opt-out flag. And if you're not reliant on any frameworks using reflection to modify final fields, there's already a flag you can use today which will instruct the JVM to "trust" and apply optimizations to `final`.