Know your Java? By Venkat Subramaniam

Really? You may wonder. This is 2023 and do we all not know Java already really well. Most of us do and yet there are so many things we tend to not realize until those things bite us in the back. This is not an introductory session on Java but one in which we will take existing code, discuss its behavior, look into surprises it holds. These are scenarios that either the speaker has stubbed his toes on or things he has been other developers stub their toes, from practical every day realistic code. We will take a number of working examples, ask you to identify the behavior, then run the code to see what it really does, and discuss the underlying concepts or the lessons we need to carry forward to avoid falling into traps or developing code that may cause issues in the future.
VENKAT SUBRAMANIAM
Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., and an instructional professor at the University of Houston.
He has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly-invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with sustainable agile practices on their software projects.
Venkat is a (co)author of multiple technical books, including the 2007 Jolt Productivity award winning book Practices of an Agile Developer. You can find a list of his books at www.agiledevel.... You can reach him by email at [e-mail] or on twitter at @venkat_s.

[@Anbu_Sampath]

As usual Venkat produced another great presentation.

[@SergeTsarik]

awesom speaker. 3 lines of code and 20 minutes of speech. I should learn it. thanx ❤

[@Skiamakhos]

38:47 - note that you can't use set to add a new element to the ArrayList. If you put for example set(3, 2) it will get an index out of bounds exception as you might expect, rather than creating a new element with the value 2. Set can only change the values of the existing ArrayList member elements.

[@adambickford8720]

Great presentation. To finish off that last part, when you want to go many-to-one you likely want `reduce` or `collect`

[@JFCostta]

You could mark the timestamp of the exercises and divide this video in sub chapters.

[@BilalOUMEHDI]

this is actually a great presentation. I learned a very important new things

[@KhanhVuy]

Super thanks, l learned new things from this presentation.

Thank you, really useful presentation

[@eldiosdelcielo]

Amazing.

[@gabstract461]

There's a mistake in the Type Inference chapter, the final output is [1,3], not [2,3]. The type of list 'numbers' is inferred as ArrayList

[@renanreismartins]

Fantastic

[@Michael-sh1fb]

Re 49:00, using 'forEach' to achieve this is certainly bad when there are choices methods available. But describing the problem as "the lambda passed to forEach has side effects" is a bad description of the problem. *Every* lambda passed to 'forEach' must have a side-effect in order to do anything useful. If that was in and of itself a problem then Stream::forEach wouldn't exist.

[@ArpitRaj]

Can the uploader please add the timestamp bookmarks? Thanks.

[@pashnyovv]

recorded slides are grayed 😢

[@lhxperimental]

2:01:44 where is *comparing* defined?

[@tiendan3108]

import static Comparator.comparing

[@hasan0770816268]

up to 21:10
explains a special bug in polymorphysim that only occurs with int list. List extends Collection so they both have a `remove` method, only List's remove expects and index and Collection's remove expects the object to remove. when we pass an int to Collection.remove it is automatically converted to Integer and if it is found in the collection then it is removed.

[@ulutiu]

that doesn't have anything to do with polymorphism.
it's because of the way calls to overloaded methods are resolved at compile time.
if compiler sees call to remove(1) and candidates are remove(int) and remove(Integer) then compiler's choice is remove(int) since it's the exact match.