Java Collections Puzzlers by Maurice Naftalin And José Paumard

[@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!

[@TaranovskiAlex]

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

[@JosePaumard]

Thank you!

[@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).

[@boyneverstop]

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

[@n_lisper]

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

[@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

[@ZordidMuc]

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

[@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!

[@ulutiu]

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

[@presmelitovillanueva812]

Haha. Did you get it right?

[@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.