It took only over 25 years (since the addition of Collection framework), but better late than never! Sequenced collections will be a blessing. No more things.get(things.size() -1). No more resorting to arrays to access reverse order. Nice!
That will be a great addition to the Java Collections Framework. However, I wonder when Project Valhalla will finally ship. Combined with Loom, this will be a major shot in the arm for the language.
The biggest chunk of Loom is currently passing the finishing line. Current JEP drafts indicate that virtual threads will be finalized and structured concurrency and scoped value APIs will be in preview soon (hopefully 21). Valhalla is still a bit to go. Personally, I don't expect anything for 21, but have big hopes for 2024.
@@nipafx Thanks for the reply. I started teaching virtual threads to my students when they came out in preview in Java 19 in Sept 2022. Virtual threads are very powerful and a great addition to the language. They are also very easy to migrate to. However, Valhalla could be a game changer for the language in a big data world. Hopefully, it'll ship in preview in the next year. Thanks again.
Indeed! I recorded that section but during editing I realized that it's not that interesting and I didn't want to end the praise with a "meh" feature (even if it comes on top). So I cut it, but forgot to remove it from the subtitle file. Fixed that now. Thanks for pointing it out! 👍
If Java had extension methods, there would be no need to write such nonsense as things.get(things.size()-1). Also, I'm really looking forward to Java 35, when finally we might get ImmutableCollection as a type. Oh well...
Is that because neither the interviewer nor the applicant watch this channel? They should've! I scored big points at a job interview in 2014 when I explained the internal tree structure of key buckets in HashMap that was introduced in Java 8.
Just like with Java, there are deeper reasons for every wart. 😜 The tiger has the same eye color as the couch and the opposing wall and I'm not gonna carve up the wall and re-wallpaper it to hide the cable. I'll probably paint it grey instead. Anyway, I'm glad that you liked the video! 😃
This is a great addition but in not a fan of the naming. . Just "Sequenced", the Collection suffix is superfluous. We don't say ListCollection. . A collection is not a bloody bean, so drop the "get" prefix. "first" and "last"is all we need. . Why the "put" nonsense. English has the perfect words: "prepend" and "append". A good addition but it can be simplified. Less is more.
I'm with you, but those method names were chosen to retrofit with the old names (e.g. in LinkedList). The other approach would have been to add new methods and deprecate the old ones (and keep them for a long time).
A list is a thing, a collection is a thing, a sequenced is a grammar mistake. A sequence would be nice but would that be the sequenced collection, sequenced set or sequenced map? And why does it have such a cool name, but the other two don't? Re method names I agree in principle, but SG explained why these names were chosen: get(i) and getFirst(), add(element) and addFirst(element), etc. just look too good together to split them up.
It took only over 25 years (since the addition of Collection framework), but better late than never! Sequenced collections will be a blessing. No more things.get(things.size() -1). No more resorting to arrays to access reverse order. Nice!
Or writing own ListUtils::getLast
So hyped for Java 29!
🤣 Who isn't? It's the LTS after the next LTS after 21!
Interesting!
Thanks for the update!
💛💙💜💚💙
That will be a great addition to the Java Collections Framework. However, I wonder when Project Valhalla will finally ship. Combined with Loom, this will be a major shot in the arm for the language.
The biggest chunk of Loom is currently passing the finishing line. Current JEP drafts indicate that virtual threads will be finalized and structured concurrency and scoped value APIs will be in preview soon (hopefully 21). Valhalla is still a bit to go. Personally, I don't expect anything for 21, but have big hopes for 2024.
@@nipafx Thanks for the reply. I started teaching virtual threads to my students when they came out in preview in Java 19 in Sept 2022. Virtual threads are very powerful and a great addition to the language. They are also very easy to migrate to. However, Valhalla could be a game changer for the language in a big data world. Hopefully, it'll ship in preview in the next year. Thanks again.
The world is small, I met Stuart Marks at the JCrete Unconference. Very nice guy btw.
He is! Very pleasant to talk to and a well of wisdom and knowledge.
just found the channel - love the videos, really good job
Thank you, Josh, that is great to hear! ❤
Nice presentation! Thank you very much! :)
As far as I have read - it is pronounced "Deck" - not "De-queue". The spelling is also only "Deque" - not "Dequeue".
From the Deque javadoc: "The name deque is short for 'double ended queue' and is usually pronounced 'deck'." 😉
Wow, when the pronunciation needs to be explained in Javadoc, that's not a good sign. 😳
¯\_(ツ)_/¯
I think this video was cut short, there are some quickly moving subtitles near the end about the return type of "Collections::unmodifiableSet"
Indeed! I recorded that section but during editing I realized that it's not that interesting and I didn't want to end the praise with a "meh" feature (even if it comes on top). So I cut it, but forgot to remove it from the subtitle file. Fixed that now. Thanks for pointing it out! 👍
Having a getAny would be nice for set as well as removeAny
Ha! I'm gonna call you as a witness in my conversation with Stuart. 😁
Why getFirst(), getLast(), etc don't return an Optional? What if the collection is empty?
Then we throw.
Nice.
Probably we will receive eventually tuples at some point
Sounds great! I wonder how it's going to work with PriorityQueue
I expect the same as with sorted sets: getting/removing first/last will work but adding not.
Nice update 👍
Thanks
If Java had extension methods, there would be no need to write such nonsense as things.get(things.size()-1). Also, I'm really looking forward to Java 35, when finally we might get ImmutableCollection as a type. Oh well...
Super easy, barely an inconvenience!
I_understood_that_reference.jpg 😂
@@nipafx wow, wow, wow.... wow
Unfortunately, we still aren't getting a tail() method. Even a view would be nice.
I predict next job interview:
-What's the differnce in Java collections?
-No difference, they are the same.
-Here the offer.
Is that because neither the interviewer nor the applicant watch this channel? They should've! I scored big points at a job interview in 2014 when I explained the internal tree structure of key buckets in HashMap that was introduced in Java 8.
@@nipafx time’s running so fast!
That Tiger is very gaudy. Hide the cable. It sticks as sequencedKeySet.. Good video though...
Just like with Java, there are deeper reasons for every wart. 😜 The tiger has the same eye color as the couch and the opposing wall and I'm not gonna carve up the wall and re-wallpaper it to hide the cable. I'll probably paint it grey instead. Anyway, I'm glad that you liked the video! 😃
This is a great addition but in not a fan of the naming.
. Just "Sequenced", the Collection suffix is superfluous. We don't say ListCollection.
. A collection is not a bloody bean, so drop the "get" prefix. "first" and "last"is all we need.
. Why the "put" nonsense. English has the perfect words: "prepend" and "append".
A good addition but it can be simplified. Less is more.
I'm with you, but those method names were chosen to retrofit with the old names (e.g. in LinkedList).
The other approach would have been to add new methods and deprecate the old ones (and keep them for a long time).
A list is a thing, a collection is a thing, a sequenced is a grammar mistake. A sequence would be nice but would that be the sequenced collection, sequenced set or sequenced map? And why does it have such a cool name, but the other two don't? Re method names I agree in principle, but SG explained why these names were chosen: get(i) and getFirst(), add(element) and addFirst(element), etc. just look too good together to split them up.
After all this time .... always
Another day, another feature copied from Scala!
I guess you need to introduce lastOptional() method, that returns None if the list is empty.