1. 22

  2. 9

    This combined with the SIMD API is a huge deal for all of those Java/Scala big data frameworks. They can reduce the memory usage and GC issues with relatively little effort. They can also remove some fragile code that uses arrays of ints/doubles in a specific pattern in hope it’ll be autovectorized.

    Making Optional a primitive object will also fix the major complaint of optionals possibly being null.

    Edit: I forgot to mention the companion JEP that lowers the overhead of boxing Integer, Double, etc. which gives more performance gains for free.

    1. 2

      I have been dreaming about Optional never being null. Perhaps, my dreams will eventually come true. Just need to wait a bit more… and then maybe a bit more again…

      1. 2

        It will probably still be nullable for bAcKwArD-coMpTtIBiLiTy reasons.

        As far as I see, the current idea is that you may be able to opt-in explicitly with additional syntax tax by writing

        Optional.val<Float> maybeFloat = ....

        everywhere, instead of

        Optional<Float> maybeFloat = ....

        (I’ll elide my remark that it is called val despite value type being the previous name of inline type primitive type.)

        1. 1

          Yeah what you wrote seems correct. The design of primitive objects is very carefully constructed to create minimal backwards incompatibility and with the ability to retrofit it on as many places as possible with minimal changes. It’s annoying from the perspective of someone that’s writing new code, but given Java’s audience of huge, slow moving enterprise software the adherence to compatability is great. I’m curious to see how Kotlin and Scala will handle this.

          Also I agree it’s weird they’re still using .val despiteit being called primitive objects now.

          1. 1

            Agreed. I think the design largely considers that “just works” simply isn’t very Java-like, where everything has to be slightly worse than it could have been with the same effort.

            Scala will probably keep being a trash fire circling around the drain and for Kotlin it only becomes relevant as soon as Android starts supporting it (so not in our lifetimes).

            1. 1

              Android has supported Kotlin for quite a while now. In fact, I doubt many new projects are written in Java anymore.

              1. 3

                I believe they meant once the Android not-JVM-runtime supports primitive objects and the associated bytecode/classfile changes, not once Android supports Kotlin.