And it's like with enums in 2004, i remember a guy predicting that nobody will use them because values() or valueOf() is always generated, you can not inherits from an enum, etc
Once a feature existed, we collectively start to twist our codes to use records instead of plain old classes. By example, choosing to use an interface with default methods instead of an abstract class with no field so subclasses can be records. Rémi ----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Donald Raab" <donr...@gmail.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Cc: "Nikhil Nanivadekar" <nikhilnanivade...@gmail.com>, "Chandra Guntur" > <chandra.gun...@gmail.com> > Envoyé: Lundi 27 Avril 2020 00:51:58 > Objet: Re: Experience Report using various Project Amber Features > This bears out one of my background assumptions about these features -- > that clean, carefully engineered codebases will benefit more from these > features than most, because they will already be well factored, > single-responsibility, leaning heavily on immutability, etc. So it's > not surprising you found immediate applications for records, for > example. The codebases that lean more heavily on mutation, probably > will have a harder time. The hope is that these features will provide a > nudge towards these practices which are good in their own right.... > > On 4/26/2020 6:22 PM, Donald Raab wrote: >> Hi All, >> >> I wanted to share our recent experience upgrading several OSS code >> katas to Java 14 with this group. We will continue leveraging new >> Project Amber and other OpenJDK project features in these katas when >> we find opportunities to. Overall, our experience has been quite >> positive. >> >> Here’s a link to the collection of katas, all of which are now >> compiling with Java 14. The katas started out on Java 8, and were >> upgraded to Java 10 two years ago. We just upgraded to Java 14 a few >> weeks ago. >> >> https://github.com/BNYMellon/CodeKatas >> >> We tagged the repo with “Java-14” on GitHub to make the Java 14 >> examples easy for developers to find. >> >> https://github.com/topics/java-14 >> >> The specific Project Amber features we are using in the katas are: >> >> 1. Local Variable Type Inference >> >> We have experimented with using the LVTI feature throughout the katas >> since Java 10 was released. This feature did not make a huge impact in >> terms of readability in the kata code itself but did prove useful in >> some cases. With the Java 14 upgrade, we introduced a proof of concept >> collections framework in the Deck of Cards Kata that adds eager APIs >> mirroring Stream protocols directly collection interfaces. The APIs we >> built in the proof of concept are implemented via default methods in >> the interfaces. Here for the first time, I was finally able to >> experiment with using LVTI in library code. This had a positive impact >> on the readability of the the library code IMO. This makes me wonder >> how much LVTI is being leveraged for good benefit in the JDK code itself. >> >> Examples: >> https://github.com/BNYMellon/CodeKatas/blob/master/deck-of-cards-kata/src/main/java/bnymellon/codekatas/deckofcards/custom/collections/MutableList.java >> https://github.com/BNYMellon/CodeKatas/blob/master/deck-of-cards-kata/src/main/java/bnymellon/codekatas/deckofcards/custom/collections/CustomCollectionsDeckOfCardsAsList.java >> >> 2. Records >> >> I tried leveraging records with Card class in the Deck Of Cards Kata. >> This worked out well and delivered the savings I had expected. Kudos! >> >> Example: >> https://github.com/BNYMellon/CodeKatas/blob/master/deck-of-cards-kata/src/main/java/bnymellon/codekatas/deckofcards/Card.java#L30 >> >> I will look to use the record feature in the Donut Kata as well for >> implementing the Donut Class. >> >> 3. Pattern Matching for instanceof >> >> This feature worked out great. Well done! >> >> Example: >> https://github.com/BNYMellon/CodeKatas/blob/master/deck-of-cards-kata/src/main/java/bnymellon/codekatas/deckofcards/custom/collections/MutableCollection.java#L24 >> >> As an OSS library developer, it is not often I get to use the latest >> available features in production library code, as providing >> compatibility to our existing client base which remains mostly on Java >> 8 makes it impossible. It was a pleasure leveraging these new features >> in the katas. >> >> Thanks, >> Don
