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.

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

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

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

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