1. 28

  2. 10

    First they ignore you, then they ridicule you, then they make clumsy imitations of your features while claiming they came up with them.

    1. 14

      I don’t think they’ll ever again miss the point so spectacularly as when they added Option tho.

      1. 4

        Same question as I have for the parent: for someone not following what happens in Java and hasn’t come across any articles about this: what’s wrong with Java’s Option?

        1. 9

          My interpretation: Option is what you use when you have non-nullable references, but you want a Nothing value. But in Java, all references are nullable per default, so what does the Option provide? Now you have two Null values: null and Nothing. Ok, then you use NonNull<Option<A>> in concert with your IDE. But that is clumsy.

          The proper solution would probably involve a new binding syntax, which would be non-nullable by default.

          1. 6

            The solution would be to add a type specifier or operator which creates explicitly non-nullable types and support that at language level because we can’t go back in time to make non-nullable a language default.

            1. 7

              I think C# is making good progress in that regard. Expect a badly copied version of that in Java 34, I guess.

            2. 5

              People always bring this up in discussions about Optional, it’s not a problem in practice. I’ve never seen someone try to return null on a method that returns an Optional and if I did it wouldn’t pass code review.

              The proper solution, which is planned, is to change it to a “primitive object” that has no identity and cannot be null. This seems to be coming relatively soon considering Valhalla has been in the works for a while and this JEP popped up recently.

              1. 3

                primitive object

                I wonder what will be the final name of this.

                has no identity

                I always found this Java-self-invented lingo pretty weird – if it’s possible to ask “is this identical to that”, it has identity. I think Java devs mixing up “same reference” with “identical” caused this confusion.

                1. 2

                  Primitive object seems to be the final name, they started with value objects, moved to inline object, and then settled on primitive object. I’m not a huge fan of it but there was some rationalization on the mailing lists.

                  I always found this Java-self-invented lingo pretty weird – if it’s possible to ask “is this identical to that”, it has identity. I think Java devs mixing up “same reference” with “identical” caused this confusion.

                  This isn’t unique to Java, C# and Python use identity in the same fashion: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/objects#object-identity-vs-value-equality https://docs.python.org/3/reference/expressions.html#is-not

                  1. 1

                    I guess it’s no coincidence that all those languages have problems with identity/equality around floating points.

                    (Which is not about floating points in particular, but they serve as a nice canary to indicate that their approach to equality/identity is broken.)

            3. 5

              Multiple methods are implemented incorrectly and violate monad laws, causing weird behavior around null. But that is “works as intended”, because Java is “pragmatic”.

              A minor nitpick is that Optional is not marked Serializable, making everyone’s life a bit more miserable than it had to be. (The explanation they gave for that was bullshit for various reasons.)

              1. 3

                I believe they forgot to make Optional be iterable, which breaks a lot of the properties it has in other languages.

                1. 4

                  You can use Optional.stream(), which you can iterate.

            4. 1

              For those not following along, what are the issues with Java records?

            5. 3

              Is this a Scala “case class” but without the destructuring implications making them useful in “pattern matching” contexts?

              1. 4

                Goetz is planning pattern matching, as linked in the final section of the link of this submission: Bierman and Goetz, September 2018.

                1. 3

                  It’s similar, as I understand it, but not for pattern matching, it’s so they can be (optionally) converted to stack-allocation in a future JDK.

                2. 1

                  InfoQ also recently had an article on this: https://www.infoq.com/articles/java-14-feature-spotlight

                  1. 1

                    Great stuff! I have been detached a bit from the Java world for a couple of years, but it do seem like the language is evolving, which makes me happy. Im still writing Java 8 code though.