Java Collections Puzzlers by Maurice Naftalin And José Paumard

The Java Collections Framework is the most widely used API - probably in your application too. You use it all the time, but do you really know your way around it? You can be surprised even by common classes like ArrayList and HashMap, let alone by the handling of null values or immutability in lesser-known classes. In this interactive session, we’ll look at some obvious code and its less-than-obvious effect. It’s up to you to guess the outcome! But everything will be explained, and you’ll end up knowing how to avoid pitfalls, both well-known and obscure, in using the Collections Framework.
MAURICE NAFTALIN
Four+ decades as a programmer, teacher, and author. Java Champion, frequent conference speaker. Disorganiser of JAlba, best unconference in Scotland! Author "Mastering Lambdas". Currently revising "Java Generics and Collections" for a second edition.
JOSÉ PAUMARD
José works as Java Developer Advocate at Oracle. PhD in applied maths and computer science, assistant professor at the University Sorbonne Paris Nord for 25 years, he is a Java Champion Alumni and JavaOne Rockstar. He is a member of the french Paris Java User Group, has been a co-organizer of the conference Devoxx France, and is a disorganizer of JChateau, an unconference held in the Chateau of the Loire Valley. He works on the dev.java documentation and community website, publishes the JEP Café, a monthly video cast on RUclips, and maintains a french RUclips channel with more than 80 hours of Java courses. He is also a Pluralsight author in the Java space.
------------------------------------------------------------
INTRO
* visuals & editing by @Mercator
* music : Avocado by Ephixa

[@that_funny_guy496]

Awesome talk, indeed these puzzlers are great source of understanding the Collections framework

[@darogajee3286]

Great talk. Please continue the puzzle

[@JosePaumard]

Thank you! Stay tune for more!

[@KnightOwl42]

Some of the puzzles are true mind-benders that show how dangerous the inconsistencies in the collection interfaces can be when the rubber meets the road, and how 'unfortunate' some of the JCL design/definition choices are (to paraphrase Oracle's own Stuart Marks on the subject). Sitting through 52 minutes of faux clueless waffling is a lot to ask, but for me it was definitely worth it. In fact, I plan on going back in there in order to transcribe the puzzles into my eternal programming notebook (CherryTree).

[@TaranovskiAlex]

Thank you for the great talk! Please continue the puzzlers indeed!)

[@JosePaumard]

Thank you!

[@boyneverstop]

I certainly have learned quite a lot from these quick puzzles. Great work!

[@neyaisselkou]

I had no idea about the Integer caching mechanism for values between -128 and 127, I disagree though with José on something he said. Getting the value of the 1000 key is still possible. Looping through the entry set of the map and using Integer::equals to compare the keys with a 1000 Integer instance can get us back the key instance for 1000. Not fancy, not saying this is good, but saying it's impossible is actually wrong :)
Great presentation by the way, learned lots of stuff about my fav language

[@mr.Aliaksei_]

Where can I download presentation

[@ZordidMuc]

Watching these Java Puzzlers makes me appreciate Kotlin even more...

[@avalagum7957]

Question 1: I blame the `var` for hiding the type of `intList`

[@ZordidMuc]

No. Blame the lack of a spread operator that needs to be used when handing in arrays as vararg arguments.

[@avalagum7957]

@@ZordidMuc So, if Java had that spread operator, we would have to write var intList = Arrays.asList(...intArray)? How does it work in Kotlin? In Scala, val a: Array[Int] = Array(1,2); val b: List[Int] = a.toList

[@ulutiu]

Can't believe so many people were fooled by 1st question

[@presmelitovillanueva812]

Haha. Did you get it right?

[@redpacifier]

I typically enjoy these kind of puzzlers, but when the interfaces are explained incorrectly to introduce the problem, I feel like the entertainment and educational value is lost. For example, question 4a - map.putIfAbsent - was explained poorly: "Does something only if the key is absent". I understand that sometimes you're trying to lead your audience to believe one thing when in fact it does not, but I found it frustrating that these interfaces (which may not be familiar to all developers) were being introduced with blatantly incorrect explanations. I still enjoyed the content, and look forward to more, but I would encourage more "vague-yet-accurate" setup explanations for these interfaces. One of the main reasons I watch content like this is to be educated, and I look to experts like you to provide accurate information. I feel like all the questions prior to 4a had appropriate introductions. With an appropriate setup (that doesn't have to fully explain the interfaces up front), it is still possible to misdirect in an entertaining and educational manner. Thanks for producing this video, and I look forward to future additions to the puzzler series!

[@mirageman2]

Maybe the half a year a new version schedule is a bad thing for the language. So many "guess what it does behaviour" is extremly dirty and the best way to doom java and get it be replaced by languages where you don't have to guess the behaviour, really sad. They should have their APIs being revised by a professional before they bring out a new version.

[@zhamed9587]

I think almost all of these have nothing to do with the half a year new version schedule. The new schedule allows us to get new previous such as Loom and pattern matching.

[@MrKar18]

If you know javascript and equality puzzles, you would have same feeling, but everyone likes JS. You ideally won't use these API like this in real word.

[@GoodTechConf]

This is indeed, very sad. They demonstrate how bad and confusiing Java API is becoming. And this is even more sad to show this on a worldwide conference. As they said, you have sometimes a view of the initial list, so it should not be a list interface. They should use something like a View interface which is inherently readonly. Sad. Poor api design.