Know Your Java?, Venkat Subramaniam

In this talk, Venkat Subramanian discusses the nuances of Java programming, aiming to highlight common mistakes that even experienced developers may encounter. He introduces the idea of 'stub your toe moments,' referring to confusing scenarios in coding that lead to unexpected behavior. Through interactive examples, he explores how the Java collection framework behaves, revealing pitfalls associated with using lists and collections, particularly with regards to the remove method. The session includes practical demonstrations of issues, such as the behavior of arrays.asList versus List.of, and emphasizes the importance of pure functions in lambda expressions to ensure code correctness. Venkat encourages developers to grasp their coding fundamentals to avoid costly errors and underscores the semantic implications of code over mere syntax. Overall, the session is designed to deepen understanding of Java's functionalities while fostering a communal learning environment.

Good morning, everyone. Um You see it's really tough. It was pouring with rain. And we were wondering will you ever showed up in this rain? But I have made special arrangements and now we have sun outside. >> [laughter] >> Exactly. So, for you to show up and uh You can't imagine how happy I am to see fully crowded room for this amazing talk. So, usually day what

day two is a little bit hard to start, but we are cheating here because we're inviting the world's best speakers to to start day two. So, uh once again just I kindly ask you, the people from I would say my left, your right part of the of the auditorium. There are still many places over there. Please take your seats there. Please don't stay there in the in

the uh by the doors or once again the fire department will punish us. Anyway, so uh It's sunny outside. Everything is good. We have our most amazing speaker Venkat Subramanian on the stage. So, please warm welcome Venkat and he's going to talk about Java. Thank you. >> [applause] >> All right. Uh thank you so much for being here. I'm going to make you work. So, I want

you to pull your cell phones out because you're going to need this throughout. Can you show it to me? Yeah, you need that. I absolutely. All right? So, let's get started. So, let's warm up first of all. And I want you to take that QR code answer the question on it. And then, we're going to keep repeating this throughout today. So, don't be shy. It's completely anonymous.

Nobody knows who is answering the questions. So, don't hesitate. while you're answering questions, I don't think you need any help for this For the questions that follow, you are most welcome to talk to people around you. I want to hear some noise in the room. So, don't just do it alone. For this, you don't need help, but for the other ones, you will need help. >> All

right, I'll give just a another few seconds. Were you able to see the question? All right, awesome. So, go ahead and point to that URL QR code if you've not had a chance to do so already. And uh we'll move real soon. All right, so that should have been enough time to answer that question. Like I said, this is the warm-up. We want to just make sure

you're all able to connect and you're able to uh you know, respond. So, oh, actually, I do need an internet connection, don't I? So, let's see. What's the connection here? I forgot that the about that totally. I'm sorry. J Prime, okay. So, there we go. Awesome. Appreciate that. Um all right, so let's take a look at what you all said with that with that response. and then

we'll move forward. There we All right, so this is the response from the group. We had 286 responses. I think we have more people in the room. So, we should really have more responses. Uh less than 10 less than 10 years uh, was about 80 68%. Uh, we have more than 10 years, about 23%. Uh, more than 20 years, about 8% and a very small percentage more

than uh, 30. Uh, that should be a chi over here, I think. >> So, awesome. Thank you. So, we have a couple of people who have more than 30 years. Uh, I did this session about 3 years ago uh, when Java was only 29 years and and anybody who said 30 was a liar. But, you know, the Java community is a very honorable community, so nobody lied

that day. So, I was very proud of the moment being belonging to a community which was that honest. So, great. Thank you so much for that. Welcome to the session on know your Java. I'm going to talk about a few things here that will surprise even the most experienced people among us. I call these as stub your toe moment. When you stub your toe, it's like ouch

and it's really hurt. And I'm not sure, honestly, when it comes to programming, which is more painful, when I stub my toe or when I watch other people stub their toes. And so, the examples I'm going to show you here are the things I've seen uh, either myself or others uh, make uh, errors along the way. So, we're going to look at some code examples. I'm going

to ask you to respond. You are most welcome to talk to people around you. So, don't be quiet. Make some noise. And then, I'll give you a little bit time and then we will review what we see there and then move forward. So, here is the first thing we're going to start about something that's been in Java for a long time and a few lessons we can

learn along the way from these as well. So, let's get to our very first example. So, what you see here is a list of numbers and I have an array list which is 1 2 and 3 as you can see. So, if I'm going to print the values, it's going to print 1 2 and 3 as you would expect. And then I remove a one and then

I ask it to print what's in there and it's going to print 1 and 3. And just to emphasize it, right? When I run the code, you can see that's exactly what it's doing. It was 1 2 3 and I do remove one, it printed 1 and 3. My question to you is, I'm going to change this one line that's there. And the change I'm going to

make is to change the list into a collection. So, the question to you is, when I to a collection, what is going to be the output? Got it? That's the question. And here is the place for you to answer. So, fire away. Again, talk to people around you. You don't have to keep it quiet. And I'm going to move this if you don't mind. Just give me

a second. I'm going to move this so it's easy for you to see and see the uh the the QR code as well. So, uh pardon me, I should be in the other window. So, let me move it up here. There we go. That's what I meant. You can talk to the person to your left, to your right, the one in front, in the back. You can

call a friend. You can call a lifeline. Don't hesitate. And we can clear up a seat over here. There we go. Thank you. So, you need your cell phone for this session. Are we ready? Give me a thumbs up if you have answered already. Beautiful. All right, wonderful then. Thank you. Appreciate that. Let's take a look at what we all responded, right? So, let's go back here.

Take a look at the response. We had about 305 responses. Good job. Thank you. And we had about one about what? 38% of us said the result is 1 3. About close to 50% said 2 3. And and a small percent eight about 8.1%. Sorry, a small percentage said 1 2. And I the answer I like the most and the one that's so difficult for a lot

of us is this beautiful I don't know. It takes courage. So, if you said I don't know, you have my request and permission, pat yourselves in the back. I wish more of us have the courage to do that, right? So, kudos. You have my respect. Thank So, now in this case, we have a 1 3 and a 2 3. What's going on? So, let's get back to

the code. So, as it turns out, this is a lesson for us to learn. When you look at a list, if you will, the list, as you know, let's just take a look at it, can we? So, if I say, list, let's say, of integer, we'll call it L, uh is equal to null for a minute, doesn't matter. L.remove And notice, when I say remove, the remove

here contains an int index. That's what you notice in the remove, right? So, you can see there's a remove with an int index. Now, when you look at a collection of integer, if you will, and again, C.remove, and when you look at it in this case, notice this contains a remove, but this remove contains an object, as you can So, notice the signature is object. So, what

do you have in this particular case? So, what you have is, literally, you have a list which contains a remove int, and you have the base, if you remember, list extends collection, and collection has object. by the way, when you have list, which is extends and then the remove contains an int, rather than an object. So, you probably know this already. When you use inheritance, and you

change the signature of a method between the base and a derived, there's a name for that. It's called a bad idea. Right? That's what it's called. Now, the reason I wanted to point to you about this is even the best among us can make these mistakes. And the Java team, I hold them in high regard, I have the deepest respect for them, but even then we can

make these mistakes. So, what happens here is when you use a list and when you call the remove, that calls the one on the list and it treats it as a index in this case. So, when you run this code with a list when a remove is called, it removes the object at that location, which was the item two uh item value two. But, unfortunately, the collection

has a remove which takes an object, which is fine most of the time. But, this is an edge case where the integer is auto boxed into an object and so it ends up removing, as you can see, the element, if you will, rather than, unfortunately, the object at the particular index. So, as a result, when you look look at the output, you can see the output in

this particular case ended up being a two three rather than being a one three. So, as it turns out, the result is two three and about 50% of the people in the room got it right. Now, that's the good news and the bad news, right? The good news is 50% got it right. The bad news is 50% got it right. Because what about the other 50%? This

is why it's confusing. When you're writing code, you don't want to be guessing these things because this is expensive. Oh, which reminds me. Don't get me wrong. I'm a huge fan of compilers because compilers verify the code for you. But, this is a code that compiled fine and yet 50% of us don't know what it's Also, don't don't get me wrong. I'm a huge fan of unit

testing. In this particular example, unit test would have given you a clue as what the code is doing. But we're going to look at some examples later on where even a unit test will not help you. So, the point is yes, compilers are great. Yes, unit testing is good. But at the end of the day, you better still know what you're doing. And if you don't know

what you're doing, thing can things can still be problematic. That's one of the reasons to really have good fundamentals. Great. So, we saw the behavior of the code right now. And the behavior in this case, as you can see, is very confusing. And it's better to design So, what's the lesson to take home? The lesson for me is when we design our own code, we should be

careful not to make such mistakes. We should make it very easy to understand and make the behavior of code very predictable. If the behavior is not predictable, it's going to cost not just us but others a lot of time and effort this is great so far, but like I said, we all make mistakes. Sometimes we stub our toes. Now, the next one is a mistake I made

and it's a bit embarrassing. And when in one of the books I was writing, I'm I mentioned a line of statement about certain behavior of a class. Now, I wrote this in the book a little too late when you print the book and publish it. But the good news is there are several amazing people in the world who have this real good skill to not make it

public but to email you directly and say, "You're stupid." And so, I love it when that happens. And this was one of those moments. Somebody wrote to me politely and said, "I'm reading your book. You have this in the book. You're wrong." And I love it when I hear that. Now, this is the reason why you write second edition of books. So, you can fix the mistakes

you made and make more new mistakes. So, essentially this is something I corrected since then, but this is my mistake. But, as you can see, we live in a very unfair world. I showed you an example, a genuine mistake the Java team made. And this is a mistake I made. But, it's a very unfair world. When the Java team makes a mistake, 10 million people know about

it. When I make a mistake, three people know about it. My wife and two kids. So, it's a very unfair game. Well, in this case, there were four people who knew about it, the person who wrote to me as well. But, let's talk about this example next. So, what I want to show you in the next example here is a one where we're going to be looking

at a behavior in the code. And the behavior in this particular case is going to be a bit troubling. But, let's take a look. The best way to do it is to look at the code, isn't it? So, here we go. So, I have a list, as you can see here. The list contains numbers is arrays.asList 1 2 3. So, the list contains 1 2 and 3.

I print what's in the list, as you would expect, 1 2 3. Then I say numbers.add and I add a four to it. And once I add, if it succeeded, it's going to print added. If it failed, it's going to print unsupported. Then I call set on the same list. If it succeeded, it's going to print set. Otherwise, it's It's to print unsupported. And in the end,

I'm printing the numbers again. So, essentially, you have a list with 1 2 3. I add a 4, and then I set the value at location 2 to 2, and then I print the list again. So, the question to you is the following. So, let's uh fire it up and see what it's uh pardon me, this one. Let's fire it up and see what it's going to

do. You can talk to your friends. You can ask. You can discuss. You don't have to go through this alone. All right. Can you give me a thumbs up if you're able to answer it? I I see a few, so I'll give a little bit more time. Not as many hands yet. How about now? Thumbs up if you've answered the question. Still not that many people are

just busy Oh, there you go. More awesome. Thank you. All right. Let's take a look at what we responded with this one, shall So, what is the mistake I did? The mistake I did is I blurted out with a detail which is incorrect. So, I was wrong uh when I said arrays.aslist creates a an immutable list. No, it doesn't. Let me show you why in just a

minute. So, let's go over here to take a look at your responses before we go further. We had about 316 response. Thank you for that. So, the first response Well, here's the beauty. Look at how the response has been, right? So, it's almost almost kind of troubling to see this, right? But, the first one was add is unsupported and set is unsupported. Who said this? 19 Is

it Yeah, 19% of the people who said this. You know why that 19% said it? Not because they are wrong. It's because they want me to feel me to feel good. That's why. Very kind people. They said, "Venkat, I know you're wrong, but we'll just support you. So, you don't have to go cry tonight, right?" So, thank you for that, people. So, yeah, 9 20 of us

20% of us are wrong, me included, right? Now, about 33% said add unsupported. And that's correct. And 15% of us said set unsupported, which is not right. And 32% of us, which is equal to the opposite of that, is actually totally incorrect as well. So, as it turns out, let's go back and run this code and see what it does. It says add is unsupported, but set

went through, which is shocking. So, what actually happened was that as list is creating a bounded list. So, you're not able to add more elements. But unfortunately, it's not immutable. It allows you to modify the element in place. So, what is the moral of the story? My recommendation is quit using uh as list because it doesn't behave as I would expect it to be, right? So, what

is the answer? We have something way better right now, which is the list.of function. So, like list.of and set.of and map.of are better. So, notice when I run this code, it says unsupported and But if I go back and modify this code just like that, and I change this to a of on the list, as you can see. So, rather than arrays.asList, I say list.of. Now notice,

both add and set are unsupported. What is the reason for that? The reason for that is when you look at this again for a minute, when I use the arrays.asList, if I say numbers. in this case, uh get class, you will notice that this is returning an array But on the other hand, if I were to go back and say that this is going to be a

list.of, it returns an immutable collections. So, as the name alludes to, that's where it's actually immutable. So, my recommendation is quit using as list and instead use list off. This is something you can easily do. You can do a grep on your code and see anywhere using as list, it's a good opportunity to use a list off rather than using that one. Great. Now, let's move a

little further this time. This one is a little bit different. And I get emails from people very often. And the email would normally go about saying, "I I listened to your talk. I, you know, listened to this idea, but I do have a question." Well, this one was an email I got from somebody who works for a very large mutual fund company. I cannot tell you the

name, but you know the name of this company. I'm not allowed to legally tell you the name. And this person's email said the following. And he said, "Hey Venkat, I have this code." And he has a code snippet. And what did the code do? The code is taking a customer information, performs a query, gets all the accounts a customer has, a rich customer, so they have a

lot of accounts, and then goes through each of the account, performs an operation, and puts the result in a list. That's basically what the code was doing. And the email from this person said, "Hey, this code worked fine until yesterday. And I made one change, and all hell broke loose. What am I doing wrong?" That was the question. Now, obviously, I cannot show you the code they

they sent me. That would be illegal for me to do so. So, I created a sample which represents the same problem here, so we can take a look at the problem maybe and see what the the problem maybe could be, right? So, let's take a look. So, what I have here a a example Let me make sure I've got the right one. Pardon me. Give me a

second. So, I want to be sure that I got the right one here. So, let's go ahead and say here is the added Okay, let's bring the next one. There we go. So, here is the collection of data as you can see. We got a strings Dory, Gil, Bruce, etc. And then I say in upper case and you have a new arrays and a name stream map

and this is returning to upper case right there. And then for each name in upper case dot add name. And I output the size and I output the results size as well. And you know, just to emphasize it, it's a seven and a seven, right? The code compiles, not a problem. So, that is the code This is the code they had with their own domain before the

change they made. Now, when they made one change as they said, all hell broke loose. So, fire up your uh uh iPhones. Let's answer that question. >> Cool. That's awesome. I like the dramatic effect. >> Love it. We should do more of that. >> All right. How about a thumbs up if you answered it? Oh, still a few more. All right, we'll We should we should play

a Jeopardy music, I think, right? All right. How about thumbs up if you All right, that's better. Okay, let's take a look what we what we saw. So, here we go. This is the for each. And we had about 340 Where are these new people coming from? Right? We keep increasing the numbers. That's awesome. Welcome. Thank you. So, the first response, about 26% of us said nothing

is beautiful the way God created. Um >> No, but sometimes God does create not so beautiful things. so, 44% the lambda passed to for each has side Beautiful. Love it. The 20% close to that said the lambda passed to for each should be a method reference. Like that's going to solve the world's problem, right? And then, of course, about 30% of us said, "I have a bad

feeling." Yeah, me, too. >> I like it. So, essentially this is a terrible code. But before we go further, please raise your hand if you've ever seen anyone write code like this in your projects with the add function. Yeah, that's a scary part, right? Yeah. But I'll tell you something even worse. I'll tell you something even worse. I've been telling people for a long time never ever

ever do this. And every time I get a chance I tell people never do this. You should see my shock when I open my own source code one morning. And I'm the only developer on this code. And I saw that. The only explanation is I did leave the window open the previous night. Who knows? Maybe an alien just got in and changed the code, right? The point

is even if you know it, sometimes you don't realize in the spirit of the moment and you make these mistakes. But it's even worse. This is a ticking time bomb. Why is it a ticking time bomb? I cannot guarantee this for you because this depends on the demo gods. And depends on whether the demo gods are going to be with us or not. When I run this

code you can see the result is seven and seven. Can anyone guess what change this programmer made that morning where everything derailed? Any guess? There you go. I see her mouth the word. Thank you. They changed it from stream to parallel stream. That's what they did. Because they wanted to run the code faster. Well, if you want the code to run fast, but you don't care if

it's correct, you should just stay with C++. Right? But you want correctness also, right? So, in this case, unfortunately, when you run it as a parallel stream, what's going to happen? My goodness, this is the day Democats were absolutely with me. Thank you, right? It never has failed on the first run like this. I Can I pass? Can I go get a lotto? This is your lucky

day. Because it doesn't work this way. Notice that it's what, seven and six. What is the result you're going to see most of the time? Most of the time, what you're going to see, Seven and seven, right? And you can run this code many, many, many, many times. And for all these runs, what you're going to see is mostly seven and seven, as you can see. But

occasionally, it's a seven and six when you lost the data. Like I said, today is my lucky day. It's failing more often than it usually. I used to spend like 10 minutes, and I'm like, I'll sacrifice a goat tonight. Please, fail. But today, it was like right on the spot. It failed. Very lucky. This also reminds me of one thing we need to really know about. Remember

that phrase, "It works on my machine." Right? You know what? I don't care. What I really like is if you are lucky, it fails on your machine. Uh if not, it fails in production. So, my mantra these days is, "It fails on my machine." Right? Because it fails on your machine, you can fix it. But if it fails on production, you know what the problem is. So,

this kind of code is a ticking time bomb, and you want to be sure not to do this. So, what is the lesson of this? The lesson here is one of the things we need to take home is uh have to be pure functions. So, lambdas have to be pure functions. This is something we need to follow as a tenant. Now, here is the problem. If you're

programming in languages like Haskell or Erlang, those languages implement purity. The compiler will yell at you if you try to make things impure. When you're writing code, those languages are very opinionated. You may come from work, you're having dinner at home, and you're thinking about code, and Haskell sits there and says, "I'm watching you." Right? Don't ever have that thought. But Java is a hybrid language. Java

doesn't enforce purity, and it's for us to make sure we don't make things impure. That's a burden on us the programmers. So, lambdas have to be pure functions, but I'll expand on this a little bit more if you don't mind, because I want to really talk about where this can become problem. So, I want to talk more about purity, but it's better to talk more about purity

once we understand the difference. But I want you to know the difference before we look at it. Notice what this code is doing. It is mutating the data that is outside the functional pipeline, so it is causing the mutation. Now, unfortunately though, when it comes to purity, we often have a a much restricted view than what we should. We need to broaden it, so we'll talk about

that a little bit more with our next So, in this example, I have a main function where I have a factor, and the factor is a value of two, as you can Now, that's in an array. Then I have a list, where the list contains one, two, and three. Then I go through a stream, and I'm transforming the data using the factor zero. So essentially all we

are doing is we are multiplying each of the numbers with the value of two. So as a result, the value being two becomes because of two, it becomes two, four, and six. But the question to you is, I modify the factor to a zero right now, and then I am printing the result. So the question to you is, what is going to be the output of that

code? So let's give it a try. That was a good ending to the music. That's how it feels too. Thank you. >> Awesome. I love this team, folks. All right, how about a thumbs up if you answered? Still a few more. I'll give a little bit more time. Thank you. Just a few more seconds. All right, then. Let's take a look what we notice here, right? So,

this one is on the stream and we had 334 responses. We had about 16% of us who said 1 2 3. Uh about 50% said 0 0 0. About 22% of us said 2 4 and 6. And about 10% said, "I have no clue. I want to go home." Uh so, the question really is, when you write code, do we want about half of the people who

are going to guess, right? That's why this is a terrible idea to be doing. So, the answer, as it turns out, is 0 0 0. So, 50% were right. But, when you run the code, as you can see, it's a 0 0 0. However, if this code were in Kotlin, the result would have been 2 4 and 6. Why? Because Kotlin, by default, does eager evaluation. But,

Java does lazy evaluation. I'm I'm sure Kai would be talking more about this in a session, most likely later this this today, because this is the laziness of streams and how they evaluate. So, streams are fundamentally lazy in Java. But, here is the problem. One of the things to keep in mind is, in in functional programming, we avoid mutability, not because it is fashionable. Uh it is

because it uh it it impacts correctness. So, essentially, as it turns out, you want to keep in mind, uh you know, functional programming relies on lazy evaluation for efficiency. And the lazy, uh you can say laziness, uh on a functional, if if you will, purity for correctness. So, this is why it's important to honor that. So, this brings us back to something we often don't realize. I

mentioned that lambdas, right? So, lambdas must be pure. So, what does it mean pure? Uh you can say, essentially, when it comes to purity of functions, right? So, lambdas, right? So, a pure you can say a pure function is item potent. So, as long as you give the same input, it'll give you the same output. I want to say two rules for functional, if you will, uh

purity. So, what does it mean uh to be pure? So, I would say, I'll give you two rules. When I state the first rule, you're going to say, "Duh, it's obvious." But, very few people think of the second rule. And both the rules are essential. One is necessary, but both of them are required to be sufficient. So, what's rule number one? The rule number one, a pure

function does not mutate uh or change anything that is visible outside. I want to emphasize this. I'm not going to stop by saying, "A pure function does not mutate or change anything." No, that's not true. A pure function can change things. That's why I emphasize cannot change anything that is So, here is a way to think about it. Immutability is like changing clothes. I hope everyone in

this room changes their clothes frequently. Otherwise, it's going to be very smelly, So, thank you for changing your clothes. It's okay to change clothes. The only thing I request is don't do that in public. That is exactly about mutability. Mutability is okay. Just don't do it in a way it's visible outside. So, essentially, that's the first rule number one. Rule number two is essentially in this case,

oops, rule number two, a pure function, you can oh, this is, by the way, real quick, example, right? So, you saw this in the previous example. We mutated the data, and you don't want to do that. But in this example, what did you notice? Notice the functional pipeline is not mutating. Right? You can say, "Gosh, my function didn't change anything, right? Am I pure?" No, this function

is not pure. Why not? That's because of rule number two. Rule number two says a pure function does not depend on anything that may change that may Sorry, that may possibly change outside. So, this is the rule number two. That's also important. So, in this example, the lambda is not pure, not because it's mutating, but it's because it's depending on a variable that might be mutated elsewhere.

So, this is something we have to be very careful in looking at things, otherwise it can be very surprising and at least 50% of us may get things wrong. But in all fairness, if I'm asked this question, "What does the code do?" My answer is, "Are you out of your mind writing code like this?" Right? Because this would be really a bad code to write because it's

hard to maintain it. So, that brings us to one more little exercise. And this will be the last one we're going to be looking at. So, here is your question. I have the stream, as you can see, and I have 1 2 3, I have parallel, and I transform the data, and I have sequential, and then I report the value. Transform tells you the thread that is

executing it and returns the result. Print reports the thread that's executing it and returns the result. So, here is a stream. I run it parallel. Transform is running after parallel, and transform is telling you the thread that's executing it. Sequential, print is running after sequential, and that's telling you the The question to you Hey, where's the music? We need a scary music right now. >> I see

a few more phones out scanning, so How about a thumbs up if you're able to answer that? That's great. Can I ask you a favor before we move forward? Just a quick pause. Can we take a minute and give a beautiful show of hands for our friends who are taking so much effort to run this wonderful conference? Thank you for the crew. Appreciate it. >> That's awesome.

So, it's it's great for our friends to put all this effort to bring the community together. We are very grateful for all the things you do, so thank you for doing this. Um all right, let's take a look at the response that we have So, we had about 325 responses. it's we have about Oh, this one here. About 30% of us say in the main thread only.

And about 30 25% of of the of us said in the common pool only. About 30% of us said either main or common pool. Uh and then finally about 18% of us said, uh please, can I call a friend? something tells me this is not about democracy. Right? We cannot just take a poll and say, let's look look at the opinions of people, right? So, it turns

out that in executes based on its characteristics. And whether the characteristics is parallel or sequential is decided by the call you make. So, whether it's parallel or sequential is only important when you hit the terminal operation. And before the terminal operation, you have ample time to change things. So, as you can see, we have a stream right now. When you run, everything is in main. Now, I

say parallel and as you can see, it is in parallel. It's using common pool. However, if I say sequential right before the terminal, everything is still sequential. So, essentially, this is not going to vary. The streams in Java do not give you sections that can run parallel and sections that can run sequential. It's a all or nothing. The entire pipeline runs sequentially or the entire pipeline runs

in parallel. So, it doesn't matter. In fact, it's even worse. You may create a parallel stream right here, right? So, parallel Now, remember, you could have created a parallel stream. We could have said var stream equal to, right? You could have done that. And then, you could have taken the stream that's given to you and you could run the forEach on it. So, I'm I mean, there's

no point in doing this in two steps, but remember, a function can create a stream and return it to you, and you can do more things with it and then call a terminal operation on it. So, imagine for a minute the above is in one function, and the bottom line is in a different function. You can see that's in parallel. But right before you use it, if

you were to take a stream and do sequential on it, right? So, uh on it. So, you're going to say uh uh uh let's try this. So, sequential uh and then you are going to execute the for each on that pipeline, let's say. Well, as it turns out, even though you said parallel to begin with, you can see in this case it's all sequential because the last

one wins. You modify the characteristics. So, the moral of the story here is we need to understand the key things here. So, this is a lesson for us to think about. So, it is you know, you uh you know, look at the syntax, but you have to see the semantics. So, the semantics, what is is important. Syntax is what you you know, what is in front of

you. You're looking at the but the syntax doesn't always matter. It's the semantics that matters the most. So, you need to really be able to see through the syntax into the semantics because that makes a difference. As we saw here, a lot of things can be very different based on the semantics in the code. And some of these are not easy to unit test. Compilers will not

tell you these things. Maybe a tool will be able to identify this a little bit better, but the onus is on us. And so, that's why it's important to take the time to really understand and get deeper with our foundation, and that's never going to change, right? We need to know what we're doing because that's our responsibility to make sure the code is behaving as expected. I

hope that was all useful. Thank you so much for your