gavinray a day ago

This post makes mention of a new JEP I hadn't heard of before: "Stable Values"

https://openjdk.org/jeps/502

https://cr.openjdk.org/~pminborg/stable-values2/api/java.bas...

I don't understand the functional difference between the suggested StableValue and Records, or Value Classes.

They define a StableValue as:

  > "A stable value is a holder of contents that can be set at most once."
Records were defined as:

  > "...  classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples."
And Value Objects/Classes as:

  > "... value objects, class instances that have only final fields and lack object identity."
Both Records and Value Objects are immutable, and hence can only have their contents set upon creation or static initalization.
  • sagacity a day ago

    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.

    • gavinray a day ago

      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;
      }
  }
      • sagacity a day ago

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

        • gavinray a day ago

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

          • sagacity a day ago

            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.