The competition is over, the prizes are given away… And despite the trainings still going on, it might be time to show the answer to my little riddle, and make a comment on it.
When explaining Java records online I was asked several times ‘right, what about Lombok?’ In particular this question was ‘if the records are immutable, how are they different from Lombok’s
When Java 14 was (about to be) released I saw a few discussions following more or less this schema: - Oh, records in Java, cool, finally we have automatically generated setters and getters! - No, records in Java are POJOs without any setters… - Oh, I see… Cool, finally in Java we have generated Beans, without any setters though!
In the previous post I wrote how to make a record and what is actually the purpose of the records. In this entry I focus on the limitations and abilities of the records.
Java 14 introduced records as a preview feature. There was (is?) a decent amount of confusion, declarations and even heavy insults against ‘enemy’ libraries and IDE plugins. Let me take part in thi s, please.
In the chase for non-trivial examples to illustrate possible usage of JEP 305, some people might have gone too far, I guess. In particular into the more challenging area of the
equals() method, present in all Java objects.
Java 14 has a lot of new features. One of them (as preview feature) is pattern matching with
instanceof. Some people programming in languages supporting the functional paradigm to some extent, e.g. Scala, Kotlin (not to mention Haskell) jumped high, full of joy ‘Yay, we gonna have
when, extracting data, guards, deconstructors in companion objects and more!’
Below you can find a piece of code written in Java. I’d like to ask you one thing: please don’t run this code before you try to answer.