Know your Java? By Venkat Subramaniam

No video

Know your Java? By Venkat Subramaniam

Рет қаралды 28,631

Күн бұрын

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 venkats@agiledeveloper.com or on twitter at @venkat_s.

Пікірлер: 20

@SergeTsarik 11 ай бұрын

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

@Anbu_Sampath 10 ай бұрын

As usual Venkat produced another great presentation.

@Skiamakhos 4 ай бұрын

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.

@JFCostta 10 ай бұрын

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

@adambickford8720 10 ай бұрын

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

@BilalOUMEHDI 7 ай бұрын

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

@KhanhVuy 10 ай бұрын

Super thanks, l learned new things from this presentation.

@eldiosdelcielo 9 ай бұрын

Amazing.

@gabstract461 9 ай бұрын

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

6 ай бұрын

Thank you, really useful presentation

@renanreismartins 3 ай бұрын

Fantastic

@Michael-sh1fb 10 ай бұрын

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 8 ай бұрын

Can the uploader please add the timestamp bookmarks? Thanks.

@pashnyovv 10 ай бұрын

recorded slides are grayed 😢

@lhxperimental 10 ай бұрын

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

@tiendan3108 10 ай бұрын

import static Comparator.comparing

@hasan0770816268 6 ай бұрын

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 5 ай бұрын

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.